Escolar Documentos
Profissional Documentos
Cultura Documentos
RENATO DE CAMPOS
UNESP
Resumo
Não é uma tarefa fácil definir requisitos para os sistemas de software que darão suporte a um negócio, dada a
dinâmica de mudanças nos processos. O levantamento de requisitos tem sido feito de forma empírica, sem o apoio
de métodos sistematizados que garantam o desenvolvimento baseado nos reais objetivos do negócio. A engenharia
de software carece de métodos que tornem mais ordenadas e metódicas as etapas de modelagem de negócios e
de levantamento de requisitos de um sistema. Neste artigo é apresentada uma metodologia de desenvolvimento
de software resultante da incorporação de atividades propostas para modelagem de negócios e levantamento de
requisitos, baseadas em uma arquitetura de modelagem de negócios. Essas atividades tornam o desenvolvimento
de software mais sistemático e alinhado aos objetivos da organização, e podem ser incorporadas em qualquer
metodologia de desenvolvimento baseada no UP (Unified Process - Processo Unificado).
Palavras-chave
Desenvolvimento de software, modelagem de negócios, processo unificado, modelagem de requisitos.
Key words
Software development, business modeling, unified process, requirements definition.
de uso de negócio. Na seção seguinte são descritas as ativida- caso, utiliza a UML como linguagem para a modelagem
des propostas a serem inseridas em metodologias baseadas dos artefatos de software produzidos ao longo do processo
no UP. Após, são apresentados os fluxogramas e descritas de desenvolvimento. O UP é fundamentado em três boas
as atividades de toda uma metodologia de desenvolvimento práticas: dirigido por caso de uso, centrado em arquitetura,
de software com as atividades propostas, assim como os iterativo e incremental. Os casos de uso definidos para um
artefatos resultantes, e as considerações finais. sistema são a base de todo o processo de desenvolvimento.
A partir de uma perspectiva de gerenciamento, o ciclo de
ENGENHARIA DE REQUISITOS E O UP vida de software do UP é dividido em quatro fases seqüen-
ciais (Concepção, Elaboração, Construção e Transição),
A engenharia de software se produz através de um con- sendo que cada fase refere-se a uma determinada meta a
junto de fases. Cada uma das fases pode envolver métodos, ser atingida ao longo do desenvolvimento.
ferramentas e procedimentos, cujas formas de estruturação Cada uma das quatro fases do UP é adicionalmente
são citadas como modelo de engenharia de software (PRES- dividida em iterações e finalizada com um ponto de
SMAN, 2002). Ainda segundo Pressman (2002), indepen- checagem que verifica se os objetivos daquela fase fo-
dentemente do modelo de desenvolvimento de software, o ram alcançados. Toda iteração é organizada em termos
processo contém três fases genéricas: definição, desenvol- de workflows de processo, que são conjuntos de ativi-
vimento e manutenção. dades realizadas pelos responsáveis pela produção dos
Quatro modelos de engenharia de software têm sido am- artefatos. Os principais workflows de processo do UP
plamente discutidos: o ciclo de vida clássico (ou cascata), são Levantamento de Requisitos, Análise, Projeto, Im-
a prototipação, o modelo espiral e as técnicas de Quarta plementação, Teste e Implantação, sendo que o RUP se
Geração (PRESSMAN, 2002). Atualmente um novo modelo diferencia, principalmente, em relação ao workflow de
tem sido bastante usado: o modelo iterativo e incremental Modelagem de Negócio.
(JACOBSON; BOOCH; RUMBAUGH, 1999; PAULA A Figura 1, conhecida como “Gráfico das Baleias”, exem-
FILHO, 2001). plifica como os workflows podem ser utilizados, com maior
A análise de requisitos é uma etapa presente na fase ou menor ênfase, em cada fase de desenvolvimento. Nela
de definição do software, independentemente do modelo podem ser observadas duas dimensões:
de engenharia de software adotado. Paula Filho (2001) – O eixo horizontal representa o tempo e mostra os as-
afirma que a engenharia de requisitos é formada por um pectos do ciclo de vida do processo à medida que se
conjunto de técnicas empregadas para levantar, detalhar, desenvolve;
documentar e validar os requisitos de um produto de soft- – O eixo vertical representa os workflows, que agrupam as
ware. Assim, é possível definir a engenharia de requisitos atividades de maneira lógica, por natureza.
como um campo da engenharia de software que visa a
aplicação de técnicas de engenharia em métodos de análise A UML foi adotada pela OMG (Object Management
de requisitos, que efetua a ligação entre a necessidade de Group) em 1997 como linguagem padrão para a modela-
informatização de processos e o projeto do software que gem de sistemas orientados a objeto. É uma linguagem para
atenderá a tais necessidades. especificação, visualização, construção e documentação
No decorrer das duas últimas décadas, uma série de méto- de artefatos de sistemas de software, como também para a
dos de análise e especificação de requisitos foi desenvolvida, modelagem de negócios e outros sistemas não necessaria-
sendo poucas as propostas que visam a sistematização da mente relacionados a software, e representa uma coleção
definição de requisitos de forma menos subjetiva (SAN- das melhores práticas de engenharia que comprovaram
TANDER, 2002). bom êxito na modelagem de sistemas grandes e comple-
O UP (Processo Unificado) é um processo estabelecido xos (OMG, 1997). Os principais diagramas da UML são:
para o desenvolvimento de software resultado de três déca- Diagrama de Classes, Diagrama de Objetos, Diagrama de
das de desenvolvimento e de uso prático. Jacobson, Booch Casos de Uso, Diagrama de Seqüência, Diagrama de Co-
e Rumbaugh (1999) apresentam as origens do UP no pro- laborações, Diagrama de Gráficos de Estados, Diagrama
cesso Objectory, que teve sua primeira versão apresentada de Atividades, Diagrama de Componentes, Diagrama de
em 1987, passando pelas contribuições do Processo Ra- Implantação.
tional Objectory (1997), até chegar ao Processo Unificado A UML também permite a ampliação da linguagem de
da Rational – RUP (KRUCHTEN, 2003). O propósito do maneira controlada, através de mecanismos de extensão, de
UP, como qualquer outro processo de desenvolvimento, forma a expressar todas as nuances possíveis de todos os
é determinar um conjunto de atividades necessárias para modelos em qualquer domínio de análise (exemplo: análise
transformar requisitos em sistemas de software. Neste de negócios), fornecendo alguma flexibilidade.
MODELAGEM DE PROCESSOS E CASOS DE bora este seja o objetivo de muitos esforços para modelagem,
USO DE NEGÓCIOS o que se tem ainda hoje é uma descrição tipicamente extensa,
inflexível e frágil (MARSHALL, 1999).
Processo de negócio pode ser definido como um conjunto A UML (Unified Modeling Language) encontra-se
de atividades conexas que toma um insumo de entrada e o atualmente consagrada para a modelagem de sistemas de
transforma para criar um resultado de saída. Teoricamente, software e tem sido proposta para a modelagem de empresas
a transformação que nele ocorre deve adicionar valor e criar através de seus mecanismos de extensão e, segundo a OMG
um resultado que seja mais útil e eficaz ao cliente que recebe (1997), esses mecanismos permitem adequá-la a novidades e
o serviço ou produto (JOHANSSON et al., 1995). Feliciano domínios específicos. As extensões definidas pelos usuários
Neto (1996) observa que a grande dificuldade encontrada na UML se dão através de estereótipos, valores associados
pelos gerenciadores de projetos de implantação de sistemas e restrições que coletivamente estendem-na e adaptam-na a
de informação para cumprir cronogramas e levantamento um domínio específico. Nas subseções seguintes são apre-
de custos está relacionada à dificuldade de delimitação de sentadas três propostas de extensões para a modelagem de
contexto do sistema. Decompor a empresa em funções de negócios com a UML, com maior ênfase na descrição da
negócio, sem se preocupar com uma visão organizacional, proposta de Eriksson e Penker (2000), já que apresentam um
facilita a definição do contexto onde o sistema de informação método mais sistemático e completo para definir e alinhar os
irá atuar. requisitos de sistemas aos objetivos do negócio.
As funções do negócio propostas por Feliciano Neto
(1996) mostram-se, na prática, como a descrição de pro- Proposta da OMG
cessos de negócios. Assim sendo, é necessário que as A OMG (1997), em sua publicação “UML extension for
metodologias de modelagem de negócios (ou de empresas) business modeling”, descreve uma extensão da UML para a
atuais tenham em sua essência o tratamento baseado em modelagem de negócios em termos de seus mecanismos de
processos. extensão. O documento, porém, não é uma tentativa de des-
Várias são as técnicas, metodologias e notações exis- crever completamente os novos conceitos e notações para a
tentes para a modelagem dos processos de empresas (KO- modelagem de negócios, apenas expõe os stereotypes que
SANKE et al., 1999; KOSANKE; NELL, 1999; SCHEER, podem ser usados para adaptar o uso da UML. Já a UML 2.0
2000; VERNADAT, 1996). No entanto, definir modelos apresenta algumas inovações em relação ao mecanismo de
de negócio é uma atividade complexa porque os usuários extensão e à modelagem de processos de negócios.
têm diferentes necessidades e estas mudam constantemente
(KALPIC; BERNUS, 2002; KIRIKOVA, 2000). Para uma Proposta de Marshall
empresa ser adaptável a mudanças, é necessário que tenha Marshall (1999) apresenta uma proposta de extensão
uma descrição simples e unificada de suas entidades e, em- da UML para a modelagem de negócios em que sugere um
metamodelo para identificar e descrever conceitos através mostra no seu topo um processo de negócio e abaixo
dos quais sistemas de negócios são delineados, utilizando a um número de pacotes horizontais chamados pacotes de
UML para ilustrar tais conceitos, e propõe uma modelagem linha de montagem, cada um representando um grupo de
baseada em quatro elementos centrais: propósito, processo, objetos, que podem ser de uma classe específica ou de
entidade e organização. diferentes classes.
Um pacote de linha de montagem é um item pacote da
Proposta de Eriksson e Penker UML estereotipado para <<linha de montagem>> e dese-
Eriksson e Penker (2000) propõem uma técnica que nhado como um longo retângulo horizontal, e o diagrama
estende a UML fundamentada em processos e orientação a de linha de montagem pode ser usado como técnica para
objetos para construir arquiteturas de negócios, baseando- levantamento de casos de uso do sistema ou de sistemas que
se no uso de extensões da UML para representar processos, darão suporte aos processos de negócio. Um exemplo de um
recursos, regras e objetivos. Afirmam que sua técnica não diagrama de linha de montagem é apresentado na Figura 2
deve ser vista como um conjunto definido de extensões para em que é mostrada a identificação de necessidades de leitu-
negócios, mas como uma base para que desenvolvimentos ras e gravações em sistemas existentes e a serem desenvolvi-
e adaptações possam ser feitos (por arquitetos de negócios) dos, e a conseqüente identificação de casos de uso relativos
para situações específicas de modelagem. ao processo de negócio “Verificação de Documentação”. O
propósito deste diagrama é mostrar
como o processo (na parte superior
Um modelo de caso de uso de negócio descreve os pro- e um sistema de software). Os casos de uso podem ser con-
cessos de negócio de uma organização em termos de casos siderados como as especificações dos serviços que o sistema
de uso e atores de negócio, correspondentes a processos de de software fornece ao processo de negócio (ERIKSSON;
negócio e clientes, respectivamente (JACOBSON; BOO- PENKER, 2000), conforme ilustrado na Figura 2.
CH; RUMBAUGH, 1999; OMG, 1997). É necessário, portanto, que a modelagem dos processos
A segunda linha corresponde às iniciativas de Marshall de negócio dê ênfase ao fluxo de informações entre os
(1999) e Eriksson e Penker (2000), que sustentam não processos ao longo da cadeia de valores que busca atingir
serem os processos de negócio bem representados pelos os objetivos globais do negócio. Atentando para isto, a
casos de uso, pois estes servem para representar um domí- segunda linha propõe a utilização de diagramas de ativi-
nio fechado correspondente a determinados requisitos de dades para a representação dos processos de negócio no
usuários e não podem ser vistos simplificadamente como domínio da modelagem de negócio, exibidos através do
requisitos de clientes. diagrama de atividade da UML, em que os itens atividade
Isto significa que um caso de uso nem sempre é equi- são estereotipados como processos, conforme o proposto
valente a um processo, pois fornece um serviço que é re- por Eriksson e Penker (2000). Faltam, porém, métodos
querido como parte de um processo exterior ao sistema de para a sistematização das etapas de definição dos proces-
software. Um caso de uso é completamente implementado sos de negócios e de definição dos requisitos de software
no software, enquanto um processo é, em geral, apenas em processos de desenvolvimento de software (tal como o
parcialmente implementado no software (o termo caso de UP), que considerem o alinhamento entre os objetivos do
uso é uma abstração para definir comunicação entre atores negócio e os requisitos do software.
<<Processo>>
Verificação de
documentação Cadastrar
Projeto
Casos de uso do
sistema a ser
desenvolvido para Verificar
apoiar o processo conformidade
Armazenar Resultados da Verif.
Consultar Análise da Conf.
Armazenar
resultado de
Cadastrar Projeto
Verificações
<<Linha de montagem>>
Catálogo de Projetos
<<Linha de montagem>>
Repositório Oracle
<<Linha de montagem>>
Sistema a ser desenvolvido
para apoiar a verificação
de documentos
Dados armazenados no
sistema a ser desenvolvido
ATIVIDADES PARA SISTEMATIZAÇÃO DO deve definir atividades e seus fluxos, bem como o estado
LEVANTAMENTO DE REQUISITOS esperado dos artefatos gerados por estas atividades em cada
fase do processo (Concepção, Elaboração, Construção, e
O UP une as boas práticas no desenvolvimento de Transição), considerando-se uma estrutura iterativa e in-
software e é base para a definição de várias metodologias cremental, bem como as atividades já definidas nesta estru-
encontradas no mercado, porém sente-se a falta de métodos tura. A aplicação da técnica de Eriksson e Penker (2000) ao
e ferramentas adequadas para o levantamento dos requisi- UP se realiza, portanto, através da criação de um workflow
tos do negócio. Assim, procura-se inserir nesse processo completo para a modelagem de negócio (que não existe
atividades para o levantamento de requisitos de sistemas originalmente no UP), da criação de novas atividades,
baseados em uma arquitetura modelagem de negócio, com e da atualização de algumas atividades anteriormente já
o intuito de tornar mais sistemática esta etapa do desenvol- estabelecidas nos workflows do UP, com a preocupação de
vimento. Para isso, é proposto um conjunto de atividades a integrá-los. São definidas também as abordagens que cada
ser inserido no UP para a modelagem de negócio, com base atividade proposta deve ter nas fases de Concepção e de
na técnica de modelagem proposta por Eriksson e Penker Elaboração. As demais atividades do UP são consideradas
(2000), incorporando em processos de desenvolvimento inalteradas, como originalmente proposto (JACOBSON;
(neste caso, o UP) as características e vantagens destacadas BOOCH; RUMBAUGH, 1999). A seguir, são descritas as
no final da seção anterior. Também são propostas atuali- atividades propostas para os três workflows (Modelagem
zações em algumas atividades preestabelecidas no UP, de de Negócio, Levantamento de Requisitos e Análise) e as
forma a poderem ser aplicadas a qualquer metodologia que abordagens das fases de Concepção e de Elaboração de
nele se baseie. um processo de desenvolvimento baseado no UP (AZE-
VEDO JR.; CAMPOS, 2004).
de nível mais estratégico até os que estejam ao nível dos Sugere-se a utilização do Diagrama de Linha de Monta-
objetivos de processos de negócio. gem como base para a realização desta atividade. Produto
Na fase de Elaboração – deve-se atualizar o modelo de resultante: Diagrama de Linha de Montagem com os
objetivos em função de possíveis esclarecimentos poste- pacotes de linha de montagem identificados.
riores.
A atividade Encontrar Atores e Casos de Uso, já existente
Modelar os Processos de Negócio no UP, foi atualizada:
Na fase de Concepção – deve-se identificar os princi- – Derivar Casos de Uso dos Processos de Negócio: os
pais processos de negócio, suas relações com os recursos casos de uso devem ser identificados com base nos pro-
(entradas, saídas, fornecedores, controles e objetivo), e a cessos de negócio. Esta atividade deve resultar em uma
seqüência de execução dos mesmos. Porém, não é necessária Relação de Casos de Uso na qual deve-se associar cada
a descrição detalhada do fluxo de eventos ocorrido interna- caso de uso identificado ao processo (ou processos) de ne-
mente no processo. gócio a que este atende. Sugere-se a utilização do Diagra-
Na fase de Elaboração – detalhar o fluxo de eventos dos ma de Linha de Montagem como base para a realização
processos que serão abordados na iteração atual. desta atividade (exemplo na Figura 2). A identificação dos
casos de uso no Diagrama de Linha de Montagem se dá
Modelar os Recursos Envolvidos através do agrupamento de referências (entre o processo
Na fase de Concepção – devem ser modelados todos os e os sistemas) de mesma natureza. Produto resultante:
recursos significativos identificados no Modelo de Processo Diagrama de Linha de Montagem com casos de uso
de Negócio definido na fase Concepção, de forma a analisar identificados.
a dependência entre tais recursos e suas propriedades.
Na fase de Elaboração – modelar todos os recursos sig-
nificativos identificados durante o detalhamento dos fluxos Abordagens das atividades propostas para Levantamento
de eventos de cada processo de negócio. de Requisitos
As abordagens destas atividades em cada fase de desen-
Modelar Comportamento dos Recursos volvimento considerada são descritas a seguir:
Na fase de Concepção – modelar o comportamento de re-
cursos nos casos em que ocorram várias alterações ao longo Identificar Necessidades de Informatização
dos processos de negócio, já que esta dinâmica de alterações Na fase de Concepção – identificar sistemas de software
precisa ser melhor entendida. que dão suporte aos processos de negócio, bem como identi-
Na fase de Elaboração – detalhar os Diagramas de Estado ficar a necessidade de novos sistemas e subsistemas. Utilizar
de Recursos, caso tenham sido criados na fase Concepção, o Diagrama de Linha de Montagem como recurso de apoio
com base no detalhamento dos fluxos de evento dos pro- ao desenvolvimento desta atividade. Deve-se começar com
cessos. os pacotes em um alto nível de abstração, representando
os sistemas já existentes e a natureza das informações das
Definir Papéis e Responsabilidades referências que estes fazem a cada processo de negócio
Na fase de Concepção – definir apenas os responsáveis analisado. Aplica-se, então, uma primeira avaliação quanto
por cada processo de negócio, sejam eles unidades organi- à natureza das informações e às operações necessárias ao
zacionais ou funções. processo e o atendimento destas pelos sistemas existentes,
Na fase de Elaboração – definir os papéis (atores) asso- de forma a identificar tipos de informações e operações que
ciados aos eventos que ocorrem no fluxo de evento de cada não estão sendo mantidas pelos sistemas de software dis-
processo de negócio. poníveis. Tais necessidades de informação e de operações
devem ser referenciadas a um outro pacote representativo
Workflow de Levantamento de Requisitos do sistema (ou sistemas) a ser construído para atender a tais
A seguinte atividade foi adicionada ao Workflow de Le- requisitos.
vantamento de Requisitos: Na fase de Elaboração – deve-se atualizar e aprofundar
– Identificar Necessidades de Informatização: nesta a análise iniciada na Concepção, com base na descrição do
atividade é necessário associar os processos de negócio fluxo de eventos dos processos. É necessário avaliar cada
aos sistemas de informação que lhes dão suporte e, assim, fluxo de evento e identificar eventos que podem ser auxi-
identificar a possível necessidade de novos sistemas de liados por sistemas de informação, mas que ainda não são.
informação, com a caracterização de carências de suporte Tais auxílios devem ser representados como referências
automatizado de informação e operações aos processos. do processo aos sistemas que os realizam. Considerando
o escopo de um sistema identificado na concepção, deve- Por ser iterativa, cada fase percorre todo o conjunto de work-
se representar cada linha de montagem como uma classe flows. Por ser incremental, cada iteração atualiza os artefatos
do sistema e distribuir a responsabilidade entre as classes gerados nas iterações anteriores. Cada Artefato corresponde a
através das referências feitas a cada uma delas pelos pro- uma documentação (como um modelo) ou outro objeto de valor
cessos. Cada evento a ser informatizado deve resultar em a ser criado no desenvolvimento (como um componente de
uma referência à classe que o realizará e quando esta não software). A metodologia da empresa também estabelece os
existir, deverá ser criada como uma nova linha de monta- estados esperados dos artefatos ao final de cada fase. Porém
gem. Este processo deve ser feito respeitando-se o conceito ela não apresenta, como o UP, atividades para o adequado
de encapsulamento. levantamento dos requisitos dos negócios.
Nesta seção são descritos os fluxogramas de atividades
Derivar Casos de Uso dos Processos de Negócio originados da incorporação das atividades propostas na me-
Na fase de Concepção – a atividade deve objetivar a iden- todologia (principalmente as fases de Concepção e Elabora-
tificação dos casos de uso arquiteturalmente significativos. ção). Nas figuras dos fluxogramas as atividades adicionadas
Estes casos de uso representam funcionalidades num alto à metodologia apresentam-se em cor cinza escuro e as ativi-
nível de abstração e servem como base para a definição da dades já constantes, mas que foram atualizadas, apresentam-
vista lógica da arquitetura do software que os realizará. se com listras. Também são apresentadas as descrições de
Na fase de Elaboração – a atividade visa identificar todos cada atividade e os estados esperados para cada artefato ao
os casos de uso do sistema com base na análise das referên- final de cada fase. Esta metodologia resultante foi utilizada
cias entre os processos detalhados e os sistemas de software no contexto do desenvolvimento de um sistema de Controle
que os apoiarão. de Expedições da empresa, sendo apresentados exemplos de
modelos gerados neste teste.
Workflow para análise
A atividade Realização de Casos de Uso, já existente no Descrição do Fluxograma da Fase Concepção
UP, foi atualizada: Na Figura 3 é apresentada a parte inicial do fluxograma
– Identificar Classes a partir da Arquitetura de Negó- de atividades resultante para a fase Concepção. A Figura
cio: esta atividade consiste na identificação de Classes 4 apresenta um modelo gerado nesta fase, na atividade
a partir de modelos da Vista de Estrutura do Negócio e de Modelagem de Processos de Negócios. O Quadro 1
da Vista de Processos de Negócio. Produto resultante: apresenta o estado esperado dos artefatos ao final da fase
Diagrama de Classes. de Concepção. Descrevem-se a seguir as atividades do
fluxograma desta fase.
Abordagem da atividade proposta para análise A.1) Entrevistar Cliente para Modelagem do Negócio:
As abordagens da atividade proposta nas fases de desen- entendimento do negócio onde o futuro Sistema atuará,
volvimento consideradas são descritas a seguir: com registro das informações levantadas num Registro de
Na fase de Concepção – busca-se a identificação das prin- Reunião, contendo um esboço do Diagrama de Contexto e
cipais Classes do sistema, com base na análise dos Modelos do Modelo de Processos de Negócio;
de Recursos e de Informações. A.2) Analisar e Modelar o Negócio
Na fase de Elaboração – deve ser feita uma reavaliação - Analisar o Negócio: Documentar a Descrição do Negó-
das Classes identificadas, com base nas referências do cio com base nas informações levantadas nas reuniões;
Diagrama de Linha de Montagem desenvolvido nesta fase. - Modelar os Objetivos do Negócio, Modelar os Processos
Através da análise das referências deve-se identificar que de Negócio (ver Figura 4), Modelar os Recursos Envol-
classes serão responsáveis pela realização dos casos de uso vidos, Modelar Comportamento dos Recursos e Definir
identificados no Diagrama de Linha de Montagem. Papéis e Responsabilidades são atividades que devem
ser feitas conforme descritas na seção “Workflow para
INCORPORAÇÃO DAS ATIVIDADES EM UMA Modelagem de Negócio” com a abordagem para a fase de
METODOLOGIA Concepção (seção “Abordagens das atividades propostas
para Modelagem de Negócios”) ;
Cada empresa que desenvolve software tem suas particu- - Registrar Termos no Glossário: para expressar os concei-
laridades e busca desenvolver suas próprias metodologias ou tos presentes no negócio, documentando no Glossário;
adaptar alguma existente no mercado. Neste trabalho utilizou- - Registrar Especificações Suplementares Principais: po-
se para teste uma metodologia de desenvolvimento de software dem ser previstos alguns requisitos não funcionais como
de uma empresa que é baseada no UP e guia o desenvolvimento relativos à segurança e à performance por exemplo, re-
dos sistemas concebidos no paradigma da orientação a objeto. gistrando em Especificações Suplementares;
Analisar e Modelar
Negócio
Registrar Termos
Glossário
no Glossário
Validar Análise
Registro de Reunião
com o Cliente
N
Modelagem do
Negócio Validada
S
Entrevistar Cliente para
Registro de Reunião
Levantar Requisitos
Analisar e Especificar
Requisitos Levantados
Esboçar Modelo de
Modelo de Caso de Uso
Casos de Uso Principais
Incrementar Glossário
Incrementar Especificações
Suplementares Principais
N Modelagem de
Requisitos Validada
S
A.3) Validar Análise com o Cliente: realizar reunião com A.7) Entrevistar Cliente para Definir Arquitetura: levan-
o Cliente para apresentar e validar a Análise do Negócio, tar informações e esboçar alternativas de Modelos de Classe
Diagrama de Contexto, Modelo de Processos de Negócio, e Pacotes, Modelo de Componentes e de Implantação em
Glossário e Especificações Suplementares; alto nível (procurando definir a arquitetura de hardware e
A.4) Entrevistar Cliente para Levantar Requisitos: levan- software em linhas gerais).
tamento das principais funcionalidades do futuro Sistema A.8) Definir Arquitetura do Software
visando a identificação dos principais casos de uso e reque- - Desenvolver Modelo de Pacotes: analisar e definir um
rimentos não funcionais, registrando as informações num Modelo de Pacotes em alto nível buscando identificar as
Registro de Reunião; relações entre eles e a possível reutilização de arquiteturas
A.5) Analisar e Especificar Requisitos Levantados de referência ou padrões;
- Identificar Necessidades de Informatização: conforme se- - Desenvolver Modelo de Classes: com as principais
ção “Workflow de Levantamento de Requisitos” e “Abor- classes do sistema e seus relacionamentos, verificando
dagens das atividades propostas para Levantamento de a possibilidade de reutilização de Classes já existentes,
Requisitos” (abordagem para a fase de concepção); utilizando a proposta da seção “Workflow para análise”,
- Esboçar Modelo de Casos de Uso Principais: conforme abordagem para a fase de concepção (“Abordagem da
seção “Workflow de Levantamento de Requisitos” e atividade proposta para análise”);
“Abordagens das atividades propostas para Levantamento - Desenvolver Modelos de Componentes: uma visão dos
de Requisitos” (abordagem para a fase de concepção); subsistemas de informação e seus relacionamentos;
- Incrementar Glossário: atualizar o Glossário com os - Desenvolver Modelos de Implantação: uma visão da
novos termos definidos nas reuniões de Levantamento de arquitetura de hardware do novo sistema;
Requisitos; - Incrementar Glossário: atualizar o Glossário com os
- Incrementar Especificações Suplementares Principais: novos termos definidos na definição da Arquitetura do
Atualizar as Especificações Suplementares com os novos Software;
requisitos não funcionais identificados nas reuniões de - Incrementar Especificações Suplementares: atualizar as
Levantamento de Requisitos; Especificações Suplementares com os novos termos
A.6) Validar Levantamento de Requisitos com Cliente: definidos na definição da Arquitetura do Software;
reunião para apresentar e validar o Modelo de Caso de - Incrementar Modelo de Casos de Uso Principais: atua-
Uso e as alterações no Modelo de Processo de Negócio, no lizar o Modelo de Casos de Uso com os novos termos
Glossário e nas Especificações Suplementares; definidos na definição da Arquitetura do Software;
A.9) Validar Arquitetura com Cliente: validar a arquite- identificação e detalhamento de outros Casos de Uso (regis-
tura geral do sistema com o cliente. trar o levantamento num Registro de Reunião);
A.10) Elaborar Cronograma Geral: para Desenvolvimen- B.3) Analisar e Modelar o Negócio: Modelar os Objetivos
to do Projeto com base nos requisitos levantados; do Negócio; Modelar os Processos de Negócio; Modelar
A.11) Elaborar Orçamento: com base no Cronograma os Recursos Envolvidos; Modelar Comportamento dos
Geral e requisitos levantados; Recursos; e Definir Papéis e Responsabilidades, conforme
A.12) Formalizar Prestação de Serviço: consiste na elabo- descritas na seção “Workflow para Modelagem de Negócio”
ração e assinatura de um contrato junto ao cliente. com a abordagem para a fase de Elaboração (“Abordagens
das atividades propostas para Modelagem de Negócios”);
Descrição do Fluxograma da Fase de Elaboração B.4) Analisar e Especificar Requisitos Levantados:
O fluxograma de atividades resultante para a fase Elabo- consiste na realização em colaboração das atividades:
ração é apresentado na Figura 5. A Figura 6 apresenta um Identificar Necessidades de Informatização (ver Figura
modelo gerado nesta fase, na atividade Identificar Necessi- 6); Incrementar Modelo de Casos de Uso (conforme seção
dades de Informatização, sendo que o Quadro 2 apresenta o “Workflow de Levantamento de Requisitos” com aborda-
estado esperado dos artefatos ao final desta fase. gem para a fase de Elaboração, seção “Abordagens das
B.1) Definir Iterações da Elaboração: definir subdomí- atividades propostas para Levantamento de Requisitos”);
nios para a fase de Elaboração com base na Arquitetura do Incrementar (atualizar) Glossário; e Incrementar (atuali-
Software e nas Especificações Suplementares definidas em zar) Especificações Suplementares;
cada iteração (deve conter o detalhamento do cronograma B.5) Desenvolver Modelos de Análise e Projeto
para a fase de Elaboração, programando o desenvolvimento - Desenvolver Realizações de Caso de Uso: para cada Caso
dos Casos de Uso por iterações); de Uso, mostrar as interações realizadas pelos objetos
B.2) Entrevistar Cliente para Levantar Requisitos: de- (Classes) necessárias à realização do caso de uso;
talhamento dos Casos de Uso já identificados bem como a - Incrementar Modelo de Classes: através da análise das
Orçamento Definido.
Plano de Iteração
Definir Iterações da
Cronograma Geral
Elaboração
Analisar e Modelar
Negócio
Modelar o Objetivo do Modelo de
Negócio Objetivos do Negócio
Analisar e Especificar
Requisitos Levantados
Identificar Necessidades Diagrama de
de Informação Linha de Montagem
Desenvolver Modelos
Modelo de Estado
de Estado
Derivar/Ajustar
Modelo de Dados
Modelo de Dados
N
Modelos de Análise e
Projetos Validados
S
Realizações de Caso de Uso e Modelo de Classes, deve-se de Classes deve-se desenvolver o Modelo de Dados,
identificar a necessidade de novas classes e incrementá- fazendo a correspondência das classes para o modelo
las no Modelo de Classes (os Diagramas de Linha de relacional;
Montagem podem ser usados como base para a identifi- B.6) Validar Análise e Projeto com o Cliente: entrevista
cação de novas classes, conforme seção “Workflow para com Cliente para validar os modelos de Análise e Projeto
Análise”, abordagem para a fase de Elaboração, seção (gerar um Registro de Reunião);
“Abordagem da atividade proposta para Análise”); B.7) Atualizar Arquitetura do Negócio: atualizar todos os
- Desenvolver Mapa de Navegação: identificar no Modelo modelos da Arquitetura do Negócio com as novas informa-
de Classes as Classes de Interface, e dentre estas as que se- ções da Análise e Projeto.
rão páginas Web, desenvolvendo o Mapa de Navegação; As atividades propostas neste trabalho abrangem princi-
- Desenvolver Modelos de Estado: para analisar e explici- palmente as fases de Concepção e Elaboração, pois é durante
tar a mudança de estados de objetos ao longo da execu- estas que os casos de uso são normalmente identificados.
ção dos processos ou eventos, desenvolvendo Modelos Portanto, as fases de Construção e Transição não tiveram
de Estado; suas atividades atualizadas ou modificadas. Para uma com-
- Derivar / Ajustar Modelo de Dados: com base no Modelo preensão mais completa da metodologia resultante, nas
2 4
5 4 Casos de Uso Identificados:
Gerar Relação de Conteúdo de cada Volume
1 3
1- Gerar Etiqueta de Objeto;
Obter informações de Origem e Destino
3- Definir Rota;
4- Manter informações dos Volumes;
Registrar Peso dos Objetos
5- Gerar Relatórios.
Gerar Lista de Volumes
<<Linha de Montagem>>
Sistema de Pessoal
<<Linha de Montagem>>
Novo Sistema
próximas seções são apresentados os fluxogramas relativos C.4) Testar Componentes: realizar testes dos componen-
às fases de Construção e Transição. tes implementados com base no Plano de Testes;
C.5) Incrementar Modelos de Requisitos e de Análise e
Descrição do Fluxograma da Fase de Construção Projeto: Atualizar Glossário com novos termos definidos;
As atividades da fase de Construção são apresentadas Atualizar Especificações Suplementares com novos requeri-
na Figura 7. O Quadro 3 apresenta o estado esperado dos mentos não funcionais identificados na Construção; Atualizar
artefatos ao final da fase Construção. as Realizações de Caso de Uso devido a possíveis necessidades
C.1) Definir Iterações da Construção: planejar a imple- de mudanças de projeto identificadas durante a implementação;
mentação de cada componente nas iterações respeitando-se Atualizar o Modelo de Classes; Atualizar Mapa de Navega-
o prazo estabelecido no Cronograma Geral (deve-se identi- ção; Atualizar Modelo de Estados com possíveis mudanças
ficar a prioridade de implementação dos componentes); ocorridas na Implementação; Atualizar Modelo de Dados com
C.2) Elaborar Plano de Testes: deve conter a descrição de possíveis mudanças ocorridas na construção do Banco;
todos os testes que serão realizados durante o projeto, bem C.6) Integrar Componentes Implementados de acordo
como o momento em que acontecerão; com o Plano de Integração definido;
C.3) Implementar: consiste das atividades Implemen- C.7) Realizar Testes Integrados com os componentes
tar Componentes (Codificação dos componentes, ge- integrados, verificando as interações entre eles;
rando os Componentes Implementados) e Implementar C.8) Desenvolver/Incrementar Manual do Sistema para
Banco de Dados (Geração do Banco de Dados com base os usuários com explicações operacionais para realização
no Modelo de Dados); das funcionalidades requeridas para o Sistema.
Plano de Iteração
Implementar
Implementar Componentes
Componentes Implementados
Incrementar modelos de
Requerimentos e de Análise
e Projeto
Atualizar Mapa de
Navegação Modelo de Classes
Atualizar Modelos
de Estado Mapa de Navegação
Atualizar
Modelo de Dados Modelo de Estado
Modelo de Dados
Versão Instalável
Transição
S
N
Desenvolver/Incrementar
Manual do Sistema
N
Iterações Programadas
para Construção Concluídas
S
Descrição do Fluxograma da Fase de Transição D5) Avaliar Manutenção: planejar a manutenção, po-
As atividades da fase Transição são apresentadas no dendo ser necessário voltar a uma das quatro fases do
fluxograma da Figura 8 e o Quadro 4 apresenta o estado desenvolvimento: Concepção, Elaboração, Construção ou
esperado dos artefatos ao final da fase Transição. Transição.
D1) Documentar Notas de Versão: descrição das funcio-
nalidades implementadas (quais os casos de uso que a versão CONSIDERAÇÕES FINAIS
realiza), da plataforma em que foi testada, de como realizar
sua instalação, Bugs, limitações e soluções conhecidas nos Neste artigo enfatizou-se a necessidade de o desenvolvi-
testes; mento de sistemas complexos de software ser guiado por
D2) Desenvolver Estratégia de Implantação: planejamen- uma metodologia ou um processo de desenvolvimento que
to para a implantação do sistema construído; organize e controle a produção das várias partes (artefatos)
D3) Implantar constituintes de um sistema. O UP contempla boas práticas
- Instalação do Ambiente de Hardware e Software: prepa- de engenharia de software, mas não define adequadamente
ração do ambiente de hardware e software do cliente para atividades para a modelagem de negócio. O RUP oferece
receber o novo sistema (preparação da infra-estrutura uma proposta de modelagem de negócio, porém, apresenta
tecnológica do cliente) ; limitações quanto à modelagem e quanto ao alinhamento dos
- Treinar Usuários: atividades de planejamento e execução casos de uso identificados aos reais objetivos do negócio. A
de treinamento dos usuários no novo sistema; técnica de construção de arquiteturas de negócio proposta
- Implantar Sistema: preparação do ambiente organizacio- por Eriksson e Penker (2000) é, dentre as propostas de mo-
nal para implantação do novo sistema; delagem de negócio com UML pesquisadas neste trabalho,
D4) Realizar Testes no Ambiente de Produção: conforme a única que aborda de forma sistemática a passagem da
Plano de Testes; arquitetura de negócio para uma arquitetura de software.
Avaliação de Teste Realizadas para cada componente e para integração de conjuntos deles.
Documentar
Notas de Versão
Notas de Versão
Implantar
S
Sistema Aprovado?
N Concepção
Avaliar Manutenção
Elaboração
Construção
Notas de Versão Notas de Versão geradas para cada versão entregue ao usuário.
Os autores, porém, não exploram a sistematização desta objetivos do negócio, atividades, classes de objetos e ne-
passagem no contexto de um processo ou metodologia de cessidades de informatização do processo de expedição)
desenvolvimento de sistemas. que não seriam (ou não seriam facilmente) identificados
O objetivo deste artigo foi descrever toda uma meto- com a metodologia normalmente usada na empresa. Isto
dologia de desenvolvimento de software com atividades indica que a metodologia resultante apresentou melho-
para a modelagem de negócio trazendo vantagens como: (i) rias com relação a uma metodologia original, puramente
identificação sistemática de necessidades de informatização baseada no UP.
a partir do fluxo de evento dos processos
estabelecido na atividade, conforme os
objetivos do negócio; (ii) identificação
sistemática dos casos de uso numa abor-
dagem iterativa estabelecida na ativida-
metodologia resultante apresentou
A
melhorias com relação a uma metodologia
original, puramente baseada no UP.
de Derivar Casos de Uso dos Processos
de Negócio; (iii) e também incorporação
de atividades de forma consistente com o modelo incremen- Atualmente, parte dos conceitos apresentados neste
tal, com interfaces bem estabelecidas com as atividades trabalho está sendo incorporada a uma metodologia
preestabelecidas do UP. de desenvolvimento de ERPs (Enterprise Resources
A metodologia resultante apresentada foi aplicada a um Planning) de código aberto (SILVA et al., 2006),
projeto piloto que correspondeu ao desenvolvimento de dentro do projeto ERP5 (www.erp5.org). Como pro-
um sistema para controle de expedição de uma empresa. posta para trabalhos futuros sugere-se a comparação
Percebeu-se por desenvolvedores, que usavam a metodo- desta técnica com demais técnicas de identificação de
logia da empresa e que também participaram do projeto requisitos, e a construção de uma ferramenta CASE
piloto, que a metodologia proposta permitiu identificar que permita maior automação das atividades definidas
requisitos e artefatos no projeto do sistema (tais como neste trabalho.
Referências
AZEVEDO JR., D. P. Aplicação da técnica de JACOBSON, I.; BOOCH, G.; RUMBAUGH, KOSANKE, K.; NELL, J. G. Standardisation Proceedings... Santa Barbara: IEEE, p.
Modelagem de Negócio com UML a processos J. The unified software development process. in ISO for enterprise engineering and 174-183, 1999.
iterativos de desenvolvimento de software. Reading: Addison-Wesley, 1999. integration. Computers in Industry, v. 40,
2003. 127 f. Dissertação (Mestrado – n. 2, p. 311-319, Nov. 1999.
Ciências de Engenharia, área Engenharia
de Produção) – Universidade Estadual do JOHANSSON, H. J. et al. Processos de negó- MARSHALL, C. Enterprise modeling with
Norte Fluminense Darcy Ribeiro, Centro cios. São Paulo: Pioneira, 1995. UML: designing successful software
de Ciências e Tecnologia, Campos dos KRUCHTEN, P. Introdução ao RUP: Rational
through business analysis. Reading:
Goytacazes, 2003. Unified Process. Rio de Janeiro: Ciência
Moderna, 2003. Addison-Wesley, 1999.
KALPIC, B.; BERNUS, P. Business process
modelling in industry: the powerful tool
AZEVEDO JR., D. P.; C AMPOS, R. in enterprise management. Computers in
Aplicação de uma Arquitetura de Industry, v. 47, n. 3, p. 299-318, 2002. ODEH, M.; KAMM, R. Bridging the gap be-
LI, H.; WILLIAMS, T. J. Management of
Modelagem de Processos de Negócios no
complexity in enterprise integration pro- tween business models and system mo-
Desenvolvimento de Software. Vértices,
jects by the PERA methodology. Journal dels. Information and Software Technology,
v. 6, n. 3, p. 147-175, 2004. KIRIKOVA, M. Explanatory capability of of Intelligent Manufacturing, v. 13, n. 6, p. v. 45, n. 15, p. 1053-1060, 2003.
enterprise models. Data and Knowledge 417-427, Dec. 2002.
Engineering, v. 33, n. 2, p. 119-136,
ERIKSSON, H. E.; PENKER, M. Business May 2000.
modeling with UML: business patterns at
OMG – Object Management Group. UML
work. New York: John Wiley, 2000. LILLY, S. Use case pitfalls: top 10
KOSANKE, K.; VERNADAT, F.; ZELM, M. extension for business modeling. v. 1.1,
problems from real projects using use
CIMOSA: enterprise engineering and cases. In: TECHNOLOGY OF OBJECT- 1997. Disponível em: <ftp://ftp.omg.
FELICIANO NETO, A. Sistemas flexíveis de integration. Computers in Industry, v. 40, ORIENTED LANGUAGES AND SYSTEMS - org/pub/docs/ad/97-08-07.pdf>. Acesso
informações. São Paulo: Makron, 1996. n. 2, p. 83-97, Nov. 1999. TOOLS, 30., 1999, Santa Barbara. em: 12 nov. 2007.
Referências
PAULA FILHO, W. P. Engenharia de soft- DE ENGENHARIA DE SOFTWARE, 16. SHEN, H. et al. Integration of business VERNADAT, F. B. Enterprise modeling
ware: fundamentos, métodos e pa- 2002, Gramado. Anais... Disponível em: modelling methods for enterprise and integration: principles and ap-
drões. Rio de Janeiro: Livros Técnicos e <http://www.lbd.dcc.ufmg.br:8080/ information system analysis and user
plication. London: Chapman & Hall,
Científicos, 2001. colecoes/sbes/2002/013.pdf>. Acesso requirements gathering. Computers
em: 10 nov. 2003. in Industry, v. 54, n. 3, p. 307-323, 1996.
Aug. 2004.
PRESSMAN, R. S. Engenharia de software.
5. ed. Rio de Janeiro: McGraw-Hill, SCHEER, A. ARIS – Business process mode-
2002. ling. 3. ed. New York: Springer, 2000. SILVA, C. M. F. et al. GERAM como arqui- VERNADAT, F. B. Enterprise modeling
tetura de referência para um ERP livre de and integration (EMI): current status
código aberto. In: ENCONTRO NACIONAL
and research perspectives. Annual
SANTANDER, V. F. A.; CASTRO, J. F B. SCHNEIDER, G.; WINTERS, J. P. Applying DE ENGENHARIA DE PRODUÇÃO, 26.
Integrating use cases and organizational use cases: a practical guide. Boston: 2006, Fortaleza. Anais eletrônicos... Rio de Reviews in Control, v. 26, n. 1, p. 15-25,
modeling. In: SIMPÓSIO BRASILEIRO Addison-Wesley, 1998. Janeiro: ABEPRO, 2006. 1 CD-ROM. 2002.
Sobre os autores
Renato de Campos
Universidade Estadual Paulista – UNESP
Professor
End.: Rua Alberto Segalla, 1-117, ap. 91A – Bairro Infante Dom Henrique – Bauru – SP – CEP 17012-634
Tel./Fax: (14) 3103-6122
E-mail: rcampos@feb.unesp.br