(Parte 3 de 5)

• Cliente/servidor • Gerenciamento de banco de dados

• Linguagens de programação, como HTML, XML, Java

• Servlets e páginas de servidor com script, como Microsoft Active Server Pages,

Java Server Pages

• Protocolos de comunicação de objetos, como a Arquitetura de Intermediador de Solicitação de Objeto Comum (CORBA) desenvolvida pelo OMG, o padrão Java de Chamada de Método Remoto (RMI) ou o Modelo de Objeto Componente Distribuído (DCOM) da Microsoft • Componentes, como o Microsoft ActiveX/COM

• Frameworks de aplicativos para a Web, como o IBM WebSphere ou o Microsoft Windows DNA

Escopo da Modelagem de Negócios

Um esforço para modelagem de negócios pode ter diferentes escopos dependendo do contexto e da necessidade. A seguir, são relacionados seis cenários possíveis.

Cenário no 1 - Organograma

Pode-se elaborar um mapa simples da organização e de seus processos para compreender melhor os requisitos do aplicativo que está sendo criado.

Nesse caso, a modelagem de negócios faz parte do projeto de engenharia de software, executado principalmente durante a fase de iniciação.

Esse tipo de esforço geralmente começa com um simples gráfico, sem nenhuma intenção de alterar a organização, mas, na verdade, a criação e a implantação de um novo aplicativo sempre têm como conseqüência algumas melhorias nos negócios.

Cenário no 2 - Modelagem de Domínios

Ao criar aplicativos com a principal finalidade de gerenciar e apresentar informações, como, por exemplo, um sistema de gerenciamento de pedidos ou um sistema bancário, pode-se optar por criar um modelo dessas informações em nível comercial, sem considerar os fluxos de trabalho do negócio.

Esse processo é conhecido como modelagem de domínios. Normalmente, a modelagem de domínios faz parte do projeto de engenharia de software e é executada durante as fases de iniciação e elaboração do projeto.

Cenário no 3 - Um Negócio, Muitos Sistemas

Na criação de um sistema grande ou de uma família de aplicativos, pode ser necessário empreender um esforço para modelagem de negócios, que servirá de subsídio para vários projetos de engenharia de software.

Os modelos de negócios ajudam a detectar os requisitos funcionais e servem de subsídio para a criação da arquitetura da família de aplicativos.

Nesse caso, o esforço para modelagem de negócios geralmente é tratado como um projeto independente.

Cenário no 4 - Modelo de Negócios Genérico

Ao criar um aplicativo que será usado por várias organizações - por exemplo, um aplicativo de suporte a vendas ou um aplicativo de faturamento - poderá ser útil passar por um esforço para modelagem de negócios, a fim de alinhar as organizações quanto à maneira como elas funcionam, evitando com isso os requisitos demasiadamente complexos para o sistema (melhorias nos negócios).

No entanto, se não for possível alinhar as organizações, um esforço para modelagem de negócios pode ajudar a entender e a administrar as diferenças sobre a forma como as organizações utilizarão o aplicativo. Dessa forma, também será mais fácil determinar a funcionalidade do aplicativo que deve ser priorizada.

Cenário no 5 - Novo Negócio

Se uma organização decidiu iniciar uma linha de negócios totalmente nova (criação do negócio) e desenvolver sistemas de informação de suporte, deverá ser realizado um esforço para modelagem de negócios.

Nesse cenário, a modelagem de negócios tem como finalidade não apenas identificar os requisitos do sistema, como também determinar a viabilidade da nova linha de negócios. Nessa situação, o esforço para modelagem de negócios geralmente é tratado como um projeto independente.

Cenário no 6 - Renovação

Caso uma organização decida renovar completamente sua forma de fazer negócios (reengenharia de negócios), a modelagem de negócios geralmente consiste em um ou mais projetos independentes. A reengenharia de negócios costuma ser feita em diversos estágios: planejar o novo negócio, fazer a engenharia reversa do negócio existente, fazer a engenharia construtiva do novo negócio e instalar o novo negócio.

Modelagem de negócios Módulo 4 – Organizações de Grande Porte

No mercado há inúmeras variações ao se definir o que é uma pequena, média ou grande empresa. Algumas definições se baseiam no número de funcionários, outras no faturamento e outras ainda em números de pontos de rede. Porém, é consenso que a diferença entre uma empresa de pequeno porte e um de grande porte está na ampla diversidade de produtos, geralmente contidos em famílias ou até séries distintas.

É comum notar que quanto maior a complexidade dos produtos, mais distribuídos serão a organização e o mercado. Isso resulta em uma quantidade maior de casos de uso de negócios mais complexos, envolvendo um número maior de funcionários com tarefas mais especializadas.

No mercado encontram-se técnicas para a modelagem de negócios que podem ser utilizadas de forma complementar e combinada ou de forma independente. As companhias complexas são as de grande porte por manterem colaboradores com alto grau de especialização. Em organizações com esse perfil, tomar decisões tornase um grande desafio e com riscos a serem corridos, tendo em vista as limitações da mente humana para formular e resolver problemas complexos.

Por mais que os executivos lancem mão de artifícios racionais nos quais os fins estão relacionados aos meios e todos os vetores são conhecidos, na realidade as decisões são calcadas em modelos simplificados. Para se contornar essa limitação, é possível construir modelos mentais ou mundos virtuais. Nos mundos virtuais existem sistemas compostos por variáveis que se inter-relacionam e o comportamento é regulado por regras de decisão para explicitar, compartilhar e aperfeiçoar os modelos mentais de um grupo de pessoas.

Os tomadores de decisão de uma organização e os proprietários do processo estão voltados aos modelos de negócios – a administração deve trabalhar com os objetivos estratégicos, enquanto os líderes e proprietários do processo necessitam ter uma visão detalhada de como o este deve ser executado.

Adoção de modelos

Caso ocorram grandes divergências entre as expectativas dos executivos e as metas dos proprietários do processo da organização, é possível solucionar as necessidades específicas desenvolvendo dois conjuntos diferentes de casos de uso de negócios, porém relacionados.

Isso pode ocorrer independentemente de serem mantidos em um ou em dois modelos separados. Em um deles, o para executivos, elege-se um conjunto de casos de uso de negócios de alto nível que mostre a intenção e a finalidade da organização; para os proprietários do processo, prepara-se outro modelo, detalhando casos de uso que esclareça os objetivos da empresa, a forma como deve funcionar, sua hierarquia, métodos, missão e metas.

A orientação é definir um ou mais casos de uso de negócios detalhados que representem as mesmas atividades da organização para cada caso de uso de negócios de alto nível. Especialistas sugerem iniciar com o gestor de negócio principal, detalhar os resultados e serviços nos quais ele está interessado ou até mesmo particularizar o próprio gestor de negócio e, em seguida, desenvolver um caso de uso de negócios detalhados para cada área.

Para desenvolver um caso de uso de negócios de cada vez, o responsável pode aplicar a técnica sugerida aos poucos. Primeiro aconselha-se a criar um modelo de casos de uso de alto nível de todo o negócio e classificar os casos de uso de negócios em uma visão geral. Depois disso, é preciso identificar um ou mais casos de uso de negócios detalhados para os casos com a melhor classificação.

É possível notar o relacionamento um-para-um entre um caso de uso de negócios de alto nível e o respectivo conjunto de casos de uso de negócios detalhados. Os relacionamentos entre os casos de uso de negócios das duas categorias são representados como relacionamentos de refinamento, um estereótipo de dependência.

Modelos superiores e subordinados

Todos os procedimentos apresentados até agora sobre a técnica de modelar casos de uso de negócios são aplicados mais facilmente em organizações que possuem uma única área de negócio e, além disso, tenham suas atividades comerciais concentradas em um só local.

Já para empresas que mantenham atividades em mais de uma região geográfica, a técnica apresentada até o momento deverá ser ampliada. Nesse caso, a modelagem para companhias com mais de uma planta, ou seja, presença em mais de um local de forma independente, mas complementares ou interligadas, pode-se criar modelos de casos de uso de negócios superior que descreva toda a atividade-fim. Depois disso, devem-se elaborar modelos de casos de uso de negócios subordinados para cada área de negócio.

Ao identificar as unidades organizacionais e mostrar como podem colaborar entre si na execução no fluxo de trabalho é possível explorar as realizações dos casos de uso de negócios superiores. Nesse nível, uma unidade organizacional corresponde a uma área de negócio.

Pode ser bastante proveitoso utilizar interfaces no âmbito do negócio para elucidar a colaboração. Sendo assim, cada área de negócio pode ser tratada como uma organização independente, completando as interfaces definidas no modelo superior de objetos de negócios.

A engenharia de software contempla uma técnica denominada divisão em camadas que visa a dominar e a diminuir a complexidade de sistemas muito grandes. Essa técnica consiste em separar as partes específicas do aplicativo daquelas mais gerais do sistema. Com isso, as unidades e os serviços do programa podem ser reutilizados.

Esses mesmos princípios, de forma geral, são aplicados na estruturação de corporações. Uma situação que pode ocorrer é a camada inferior conter os recursos que oferecem serviços gerais; na camada no meio, geralmente, ficarem os recursos que possibilitam as ações específicas da atividade-fim e, por fim, na camada superior se situarem os especialistas da área de negócio ou do produto; pesquisa e desenvolvimento e tarefas de vendas. Todas as camadas deixam acessíveis recursos aos casos de uso de negócios centrais.

Os critérios para a separação das camadas são única e exclusivamente referenciais e não implicam em qualificações ou juízo de valor. Um colaborador de negócio na camada de habilidades gerais pode efetuar uma tarefa tão importante quanto as demais. As tarefas, nos casos de negócios centrais e nos auxiliares, nos quais são desenvolvidos sistemas de informação específicos do negócio, linhas de produção e outros tipos de infra-estrutura de negócios, podem exigir as mesmas habilidades específicas da organização dividida em camadas.

Classes de camadas

Estruturar a organização em camadas altera a efetivação do caso de uso de negócios, sendo ainda necessário produzir os mesmos resultados. O responsável pelo projeto deve estar alerta a algumas restrições pertinentes ao modelo de objetos de negócios em camadas, diferente de um modelo de objetos de negócios não dividido em camadas.

Entre elas estão: um colaborador de negócios de uma determinada camada nunca entra em contato com um trabalhador de negócios ou manipula uma entidade de negócios de uma camada superior, exceto se requisitado por um membro da camada superior; e um trabalhador de negócios tem responsabilidades somente dentro de sua própria camada. Se essas restrições não forem observadas, corre-se o risco de uma estrutura em camadas não ter aderência.

(Parte 3 de 5)

Comentários