Embed Size (px)
Citation preview
SOELI TERESINHA FIORINI
ARQUITETURA PARA REUTILIZAÇÃO DE PROCESSOS DE SOFTWARE
TESE DE DOUTORADO
DEPARTAMENTO DE INFORMÁTICA
Rio de Janeiro, Abril de 2001
SOELI TERESINHA FIORINI
ARQUITETURA PARA REUTILIZAÇÃO DE PROCESSOS DE SOFTWARE
Dissertação apresentada ao Departamento de Informática da Pontifícia Universidade Católica do Rio de Janeiro, como parte dos requisitos para obtenção do grau de Doutor em Informática. Orientador: Julio Cesar Sampaio do Prado Leite
Departamento de Informática Pontifícia Universidade Católica do Rio de Janeiro
Rio de Janeiro, 25 de Abril 2001.
II
ao Flávio Amorim e minha família, por todo amor e incentivo.
III
Agradecimentos
Esta tese não teria sido possível sem a ajuda indispensável de várias pessoas. A elas, eu gostaria de expressar os meus sinceros agradecimentos:
Meu orientador e amigo Julio Cesar Sampaio do Prado Leite, quem me acompanhou durante todo o mestrado e doutorado, passando-me conhecimentos, quem sempre confiou no meu trabalho, compreendendo minhas necessidades, meu estilo, minhas indecisões, quem realmente orientou-me para que eu definisse meu próprio caminho, fazendo o que eu gosto. À Isabel Rosseti pela revisão da tese, presteza, amizade de anos e incentivo durante a elaboração da tese. À Eliana Almeida, Andrea Pizzol, Simone Martins e Rodrigo Uchôa pelo companheirismo e amizade. À Virginia Kayser pela grande colaboração e suporte durante esta tese.
À Valdirene Gonçalves Vieira por me ouvir e estar junto nos momentos difíceis. À Débora Luccas pelo convívio amigo e incentivo durante a elaboração da tese. Ao Cassiano Fróes pelo supporte no desenvolvimento da ferramenta, sem a qual não teríamos como validar meu trabalho. Aos meus amigos da PUC, pelos momentos alegres e felizes juntos dividos. À URI Santo Ângelo/ CAPES e Uniway pelo apoio financeiro. Aos que de uma forma ou outra contribuíram para a conclusão desta tese.
IV
Resumo
O trabalho desenvolvido nessa tese propõe uma arquitetura para a organização e
descrição de processos, visando a reutilização. Esta arquitetura é baseada em tipos de
processos (standard, pattern e usual), em frameworks de processo, e em diferentes tipos
de linguagens de modelagem de processos, especificadas em XML – Extensible Markup
Language, para descrever cada um dos tipos de processos. Com a finalidade de facilitar a
reutilização e recuperação de informações se faz uso de facetas, guias de reutilização e
utiliza-se process patterns organizados e classificados em comunidade, família e
indivíduo. Alguns processos de engenharia de requisitos foram analisados para criar um
framework de processos e uma ferramenta foi desenvolvida para viabilizar um estudo de
caso e validar o uso da arquitetura proposta. O estudo de caso demonstra a utilização da
arquitetura e uso da ferramenta na reutilização e definição de processos, definindo um
processo de engenharia de requisitos para um projeto de uma empresa do setor de
informática.
Abstract
This thesis presents an architecture for the organization and description of software
processes. Its main goal is to enable software process reuse. The architecture is
organized by three different process types (standard, pattern and usual) and by the
concept of process framework. Processes are described according to their process type
and by special languages, which are based on XML (Extensible Markup Language). In
order to help the retrieval of process information, the architecture provides a facet
classification schema, a 3C-based reuse guide, and a process pattern classification
(community, family and individual). A prototype tool implements the architecture. A
requirements engineering process framework was built in order to explore the
architecture capabilities. A case study on the reuse of requirements engineering process
was conducted.
V
Sumário
CAPÍTULO 1– INTRODUÇÃO........................................................................................................... 10
MOTIVAÇÃO/ PROBLEMAS .................................................................................................................. 10
1.1.1 As pesquisas .................................................................................................................... 10
1.1.2 Maturidade das empresas x definição e melhoria dos processos....................................... 12
1.1.3 Reutilização de Processos x Frameworks/Patterns ........................................................... 14
DESCRIÇÃO DAS CONTRIBUIÇÕES ........................................................................................................ 16
ORGANIZAÇÃO DA TESE ...................................................................................................................... 18
RESUMO ............................................................................................................................................. 18
CAPÍTULO 2– CONCEITOS BÁSICOS............................................................................................. 19
PROCESSOS ......................................................................................................................................... 19
REUTILIZAÇÃO DE PROCESSOS............................................................................................................. 22
FRAMEWORKS .................................................................................................................................... 25
2.1.1 Definição de Frameworks ................................................................................................ 25
2.1.2 Como Desenvolver Frameworks....................................................................................... 28
2.1.3 Tipos de Frameworks...................................................................................................... 33
PATTERNS........................................................................................................................................... 34
FACETAS ............................................................................................................................................ 35
XML – EXTENSIBLE MARKUP LANGUAGE........................................................................................... 36
XSL – eXtensible Stylesheet Language ........................................................................................... 41
RESUMO ............................................................................................................................................. 43
CAPÍTULO 3 – A ARQUITETURA PARA REUTILIZAÇÃO DE PROCESSOS ............................ 45
VISÃO GERAL ..................................................................................................................................... 45
LINGUAGEM DE MODELAGEM DE PROCESSOS ....................................................................................... 47
TIPOS DE PROCESSOS........................................................................................................................... 48
3.1.1 Process Standard ............................................................................................................. 49
3.1.2 Process Patterns .............................................................................................................. 51
3.1.3 Usual Process.................................................................................................................. 53
INSTÂNCIAS DE PROCESSO .................................................................................................................. 54
FRAMEWORK DE PROCESSO ................................................................................................................. 55
GUIAS DE REUTILIZAÇÃO .................................................................................................................... 56
RESUMO ............................................................................................................................................. 63
VI
CAPÍTULO 4 – A LINGUAGEM DE MODELAGEM DE PROCESSOS ......................................... 64
MODELOS DE PROCESSOS ..................................................................................................................... 64
4.1.1 Pesquisas anteriores com processos de software .............................................................. 65
4.1.2 Organização e descrição de processos voltada para a reutilização ................................... 66
LINGUAGEM DE MODELAGEM DO USUAL PROCESS ............................................................................... 70
LINGUAGEM DE MODELAGEM DO PROCESS PATTERN ........................................................................... 75
LINGUAGEM DE MODELAGEM DO PROCESS STANDARD ......................................................................... 83
RESUMO ............................................................................................................................................. 88
CAPÍTULO 5 – DESENVOLVIMENTO DE FRAMEWORKS DE PROCESSOS............................. 90
FRAMEWORK DE PROCESSO ................................................................................................................. 90
5.1.1 Processo de Desenvolvimento de Framework de Processo................................................ 93
EXEMPLO DO GUIA DE REUTILIZAÇÃO ............................................................................................... 102
DIFICULDADES PARA MONTAR O FRAMEWORK DE PROCESSOS ............................................................ 108
RESUMO ........................................................................................................................................... 109
CAPÍTULO 6 – REUTILIZAÇÃO DE PROCESSOS....................................................................... 111
REUTILIZAÇÃO DO FRAMEWORK X ESCOLHA LIVRE DE COMPONENTES ................................................ 111
O PROCESSO DE REUTILIZAÇÃO DE PROCESSOS................................................................................... 113
A FERRAMENTA................................................................................................................................ 125
6.1.1 Cadastro........................................................................................................................ 125
6.1.2 Pesquisa ........................................................................................................................ 128
6.1.3 Reutilização................................................................................................................... 132
6.1.4 VisualizaçÃo do processo em xml/xsl.............................................................................. 135
RESUMO ........................................................................................................................................... 136
CAPÍTULO 7– ESTUDO DE CASO.................................................................................................. 138
O ESTUDO DE CASO VIA WEB ........................................................................................................ 138
7.1.1 Atividades...................................................................................................................... 138
7.1.2 Descrição Sumária do Projeto ....................................................................................... 139
7.1.3 Modelo de relacionamento Proposto para o Cliente da Empresa Y ................................. 139
A REUTILIZAÇÃO .............................................................................................................................. 141
EXPERIMENTO .................................................................................................................................. 146
CAPÍTULO 8 – CONCLUSÕES E TRABALHOS FUTUROS......................................................... 148
CONCLUSÕES.................................................................................................................................... 148
8.1.1 A arquitetura proposta................................................................................................... 149
VII
8.1.2 Linguagens de modelagem de processos......................................................................... 149
8.1.3 Desenvolvimento de frameworks de processo ................................................................. 150
CONTRIBUIÇÕES................................................................................................................................ 153
8.1.4 A arquitetura para reutilização de processos de software ............................................... 153
8.1.5 Engenharia de requisitos................................................................................................ 155
TRABALHOS FUTUROS....................................................................................................................... 156
8.1.6 Estudos de caso ............................................................................................................. 156
8.1.7 Gerência de configuração e adaptação dos processos .................................................... 156
8.1.8 Guias de Reutilização .................................................................................................... 157
8.1.9 Pesquisa e recuperação de informações ......................................................................... 157
8.1.10 Evolução do protótipo da ferramenta ............................................................................. 157
8.1.11 Outras sugestões............................................................................................................ 158
REFERÊNCIAS ................................................................................................................................. 159
ANEXOS A – DTDS E DOCUMENTOS XML ................................................................................. 165
DECLARAÇÕES ................................................................................................................................. 165
8.1.1 DeFinição do Tipo de Documento – DOCTYPE ............................................................. 165
8.1.2 Declaração do Tipo de Elemento –- !ELEMENT ............................................................ 166
8.1.3 Declarações de Atributos – ATTLIST ............................................................................. 167
DTD – USUAL PROCESS ................................................................................................................... 168
DTD – PROCESS PATTERN ................................................................................................................ 174
DTD – PROCESS STANDARD ............................................................................................................. 178
DOCUMENTO XML – PROCESS STANDARD (EXEMPLO) ...................................................................... 181
DOCUMENTO XML – USUAL PROCESS (EXEMPLO) ......................................................................... 186
DOCUMENTO XML – PROCESS PATTERNS (EXEMPLO).................................................................... 191
ANEXO B – QUESTIONÁRIO INICIAL.......................................................................................... 195
ANEXO C – QUESTIONÁRIO FINAL............................................................................................. 198
ANEXO D – ESTUDO DE CASO DA EMPRESA Y......................................................................... 200
VIII
Lista de Figuras
FIGURA 1- DIAGRAMA SADT DAS ATIVIDADES DESTA TESE...................................................................... 16
FIGURA 2 – PROCESSO DE DESENVOLVIMENTO DE UM FRAMEWORK – PREE [34]........................................... 29
FIGURA 3 – HOT SPOT CARD – FAYAD ET ALL [47] ................................................................................... 30
FIGURA 4 – ATIVIDADES DO DESIGN DO FRAMEWORK – FAYAD ET ALL [47] .............................................. 32
FIGURA 5 - PROCESSO DE DESENVOLVIMENTO DE FRAMEWORKS – FONTOURA [48] ................................... 32
FIGURA 6 – EXEMPLO DO ESQUEMA DE CLASSIFICAÇÃO POR FACETAS - PRIETO-DÍAZ [38]......................... 36
FIGURA 7 – O XML ............................................................................................................................... 38
FIGURA 8 – EXEMPLO DE DOCUMENTO BEM DEFINIDO (A) E UM DOCUMENTO VÁLIDO (B).......................... 40
FIGURA 9 – ARQUITETURA PARA REUTILIZAÇÃO DE PROCESSOS ............................................................... 46
FIGURA 10 – OPERAÇÕES REALIZADAS PARA GERAR INSTÂNCIAS DE PROCESSOS. ...................................... 55
FIGURA 11 – GUIA DE REUTILIZAÇÃO....................................................................................................... 57
FIGURA 12 - DIAGRAMA DA BASE DE PROCESSO PARA USUAL PROCESS E ELEMENTOS AUXILIARES.............. 71
FIGURA 13 – DIAGRAMA DO ELEMENTO USUAL PROCESS .......................................................................... 73
FIGURA 14 – DIAGRAMA DO ELEMENTO ATIVIDADE MACRO DE UM USUAL PROCESS................................... 75
FIGURA 15 - PROCESS PATTERN SOCIETY: ORGANIZAÇÃO DOS PROCESS PATTERNS.................................... 77
FIGURA 16 – DIAGRAMA DO ELEMENTO PROCESS PATTERN SOCIETY – COMUNIDADE ................................. 80
FIGURA 17 – DIAGRAMA DO ELEMENTO PROCESS PATTERN FAMÍLIA ......................................................... 81
FIGURA 18 – DIAGRAMA DO ELEMENTO COMPONENTE DA SOLUÇÃO DE UM PROC. PATTERN FAMÍLIA ......... 82
FIGURA 19 – DIAGRAMA MINIMIZADO DO PROCESS STANDARD ................................................................. 84
FIGURA 20 – DIAGRAMA DO ELEMENTO SEÇÃO DE UM PROCESS STANDARD. .............................................. 85
FIGURA 21 – DIAGRAMA DO ELEMENTO SUBSEÇÃO DE UM PROCESS STANDARD ......................................... 86
FIGURA 22 – DIAGRAMA DO ELEMENTO ITEM DE UM PROCESS STANDARD ................................................. 87
FIGURA 23 – REUTILIZAÇÃO DE PROCESSOS ........................................................................................... 111
FIGURA 24 – PAGINA PRINCIPAL ............................................................................................................ 126
FIGURA 25 - CADASTRO ELEMENTOS DO PROCESSO (TABELAS AUXILIARES) ............................................ 127
FIGURA 26 – CADASTRO DO USUAL PROCESS .......................................................................................... 127
FIGURA 27 – PESQUISA PARA USUAL PROCESS ........................................................................................ 128
FIGURA 28 – PESQUISA PARA PROCESS PATTERN .................................................................................... 129
FIGURA 29 – PESQUISA DO PROCESS STANDARD ..................................................................................... 129
FIGURA 30 – PESQUISA DO PROCESS PATTERN – REALIZADA DE FORMA MAIS ESTRUTURADA.................... 130
FIGURA 31 - RESULTADO DA PESQUISA, VISUALIZAÇÃO DO PROCESSO COM SUAS ATIVIDADES E
REUTILIZAÇÃO DAS ATIVIDADES ................................................................................................... 131
IX
FIGURA 32 – COMPARAÇÃO DE ATIVIDADES DE PROCESSO ...................................................................... 131
FIGURA 33 – REUTILIZAÇÃO USUAL PROCESS – TOTAL............................................................................ 132
FIGURA 34 – ESCOLHA DO FRAMEWORK E VISUALIZAÇÃO DE SUAS ATIVIDADE PARA CONSULTA .............. 133
FIGURA 35 – REUTILIZAÇÃO UTILIZANDO UM FRAMEWORK .................................................................... 134
FIGURA 36 – CONSULTA AOS DADOS DA ATIVIDADE MACRO DO FRAMEWORK/ COMPONENTE ................... 135
FIGURA 37 – VISUALIZAÇÃO DA INSTÂNCIA DO PROCESSO EM XML/XSL ............................................... 136
FIGURA 38 – MODELO DE RELACIONAMENTO ENTRE EQUIPES. ................................................................ 140
FIGURA 39 – PROCESSO SIMPLIFICADO DA RATIONAL............................................................................. 141
FIGURA 40 – PROCESSO DA EMPRESA Y SENDO DEFINID: ATIVIDADES SIMILARES. .................................. 143
FIGURA 41- REUTILIZANDO ATIVIDADES DE UM PROCESS STANDARD...................................................... 144
FIGURA 42 – PROCESSO DA EMPRESA Y COM AS ATIVIDADES DE UM PROCESS PATTERN. ......................... 145
10
Capítulo 1 – Introdução
Este trabalho apresenta uma proposta sistemática para a organização e descrição de processos
de software, visando a reutilização. Neste capítulo, expõe-se a motivação deste trabalho, citam-
se problemas relacionados com os processos e a sua reutilização, descreve-se genericamente a
solução proposta, apresentam-se, de forma sucinta, suas contribuições e finalmente, define-se a
organização da tese.
MOTIVAÇÃO/ PROBLEMAS
A motivação e os problemas relacionados ao nosso trabalho estão relatados em três itens:
as pesquisas, a maturidade das empresas versus a definição e melhoria dos processos, e a
reutilização de processos versus frameworks1 e patterns2. Estes itens estão descritos a
seguir.
1.1.1 AS PESQUISAS
O crescente interesse em processos foi uma evolução de estudos centrados em produtos
que verificaram que a qualidade do que era produzido tinha uma forte relação com o
processo que era utilizado para produzi-lo [1]. Keller e Teufel [2] também mostram que o
próprio desenvolvimento organizacional, desde as idéias de Adam Smith (1723-1790),
que dividiu o trabalho em tarefas especializadas, passando entre outros, pelas idéias de
Taylor e paradigmas de design de processos de negócio (entre outros, engenharia
simultânea, cadeias de valor agregado, gerência de workflow e (re)-engenharia do
negócio), conduziu organizações ao trabalho mais orientado a processos.
Em 1984, no Primeiro Workshop Internacional de Processo de Software (First
International Workshop on Software Processes - ISPW [3]) um grupo de pesquisadores
tomou ciência da nova disciplina em tecnologia de processos que emergia. Depois disto,
1 “Um framework é o esqueleto de uma aplicação que pode ser customizada por um desenvolvedor da
aplicação” (em [47]).
2 Patterns são soluções genéricas para problemas recorrentes (em [33] ).
11
vários workshops e conferências em tecnologia de processos têm sido realizados (ISPW
[4], ICSP [5], IPTW [6], EWSPT [7], FEAST [8] e PROFES [9]).
Grupos nacionais e regionais também começaram a organizar seus workshops (IPSJ,
JSPW e SIG [10]). No Brasil, por exemplo, tem-se o SIMPROS (Simpósio Internacional
de Melhoria de Processos de Software) [11] com o intuito de fazer algo similar ao
Software Engineering Process Group Conference (SEPG Conference) [12], a primeira
conferência para demonstrar casos práticos para profissionais de processos de software.
O SPIN (Software Process Improvement Network) também é um exemplo de rede de
pesquisa e troca de experiências em melhoria de processos, que acontece em vários
países, inclusive no Brasil [13].
Vários aspectos relacionados aos processos têm sido pesquisados, como por exemplo:
definição explicita de um processo de software [14][15], ambientes de engenharia de
processo de software com foco em processos [16], melhorias no processo de software
[17][18][19][20] e definição de process pattern [21], [22], [23], [24], [25] e [26]. Poucas
pesquisas têm sido relatadas com respeito a reutilização de processo de software [27],
[28] e [29]. A maior parte dos trabalhos de reutilização têm ênfase nos aspectos da
reutilização do código e design , por exemplo [30], [31], [32], [33], [34], [35] e [36].
O SAP-R/3 [2] é um caso de reutilização de processos bastante popular, entretanto
voltado para processos de negócio. O Sistema R/3 consiste de módulos de aplicações de
negócio (processos orientados para a implementação) que podem ser usados tanto
individualmente quanto em combinações. A estratégia envolve entregar um sistema
completo para o cliente ativando os processos de negócio e funções necessárias de acordo
com os requisitos do cliente. Segundo Keller e Teufel [2] a desvantagem desta estratégia
é que requer de alguns clientes um trabalho muito grande de configuração do sistema no
início da implementação. A vantagem é que no decorrer das operações, é fácil ativar
funcionalidades de um “pool” de soluções que continuamente cresce. A reutilização dos
processos é realizada em conjunto com a reutilização do software que os implementam.
Dentre todas as propostas (ou promessas) para melhorar o desenvolvimento de software,
torna-se claro que a reutilização sistemática e a construção de software baseado em
12
componentes são ainda uma das mais promissoras [37]. A reutilização reduz tempo,
melhora a qualidade e reduz custos, embora não seja trivial. Prieto-Diaz [38] aponta três
tendências emergentes que podem ajudar a solucionar problemas de reutilização: análise
e engenharia de domínio, reutilização de processos e megaprogramação. Ele comenta que
a “comunidade está verificando a possibilidade de criar coleções de processos
reutilizáveis que podem ser conectados para instanciar novos e mais complexos
processos”. Ele também salienta que a reutilização de processo é um meio de reutilizar
experiências (práticas) e conhecimento, no entanto, “esta área tem recebido muito pouca
atenção da comunidade de reutilização (....) tem um tremendo potencial, mas é preciso
mais pesquisas”.
1.1.2 MATURIDADE DAS EMPRESAS X DEFINIÇÃO E MELHORIA DOS
PROCESSOS
Atualmente, dentro do movimento de melhoria de processos, muitas empresas de
software buscam cada vez mais atingir a maturidade de seus processos [41], tendo como
base a sua melhoria e definição. Entretanto, a busca pela maturidade tem, entre outros,
um alto custo, necessita do envolvimento da gerência e equipes, de dados de processos,
de pessoas com conhecimento em modelagem de processos, de modelos para a definição
de processos, de treinamentos e de mudança cultural. Uma infinidade de fatores, impondo
dificuldades, faz com que empresas despendam longos períodos de tempo para definirem
alguns de seus processos [41], sem contar aquelas que desistem no meio do processo de
maturidade.
Um método muitas vezes citado para acelerar este processo dentro de uma organização é
replicar um processo organizacional dentro de outros projetos. Desta forma, as descrições
de processos são muito importantes porque elas permitem que o conhecimento seja
reutilizado, o que é tema de pesquisas na área de Learning Software Organizations [42]
[43]. Entretanto, a criação de um processo que é usado em diversos projetos é uma tarefa
bastante difícil [29].
13
Muitas organizações estão buscando a definição de um processo de software padrão, um
processo comum para todos os projetos da organização. Este processo descreve os
principais elementos do processo de software que cada projeto deveria incorporar no seu
processo de software definido [40]. Geralmente a definição deste processo é uma
generalização de vários processos específicos e pode estar em conformidade com algum
modelo ou norma. No entanto, organizações com pouca maturidade ou não têm nenhum
processo definido (tendo que defini-lo com base em suas experiências e/ou literatura) ou
se têm, é deficiente e não é padrão na organização.
Uma vez definido o processo padrão é preciso saber como adaptá-lo para as
características específicas dos projetos. Algumas pesquisas mostram as dificuldades desta
atividade, por exemplo [45] e [46].
Modelos, tais como o CMM [39] ou o paradigma de programação do processo de
software [14], têm como objetivo seguir um processo definido e ter um padrão. No
entanto, raramente têm o conceito de reutilização de processos e de seus artefatos como
um objetivo central [28]. No caso do CMM, por exemplo, no Nível 3 existe uma área-
chave a ser trabalhada que é a Definição do Processo da Organização, ou seja, é preciso
definir um processo de software padrão que deve ser adaptado às características
específicas dos projetos [40] [44]. Porém, ele não diz como fazer isto e o mercado
raramente fornece modelos ou frameworks de processos que possam ser reutilizados (uma
iniciativa recente são os process patterns [36], [21] e o Rational Unified Process [46]).
Muitas organizações têm que iniciar a definição de seus processos baseados em algum
conhecimento tácito existente ou baseados, unicamente, em bibliografias que requerem
muito tempo para que sejam entendidas, pois muitas vezes possuem inconsistências.
Como outra opção, também se inicia a definição com base em modelos ou normas, como
por exemplo, ISO e CMM. Entretanto, estas além de serem genéricas, precisam de
interpretação e nem sempre apresentam suas atividades de forma explicita. Medições do
esforço de definição de processos, para projetos e organização, relatam que é necessário
14
para uma área-chave (CMM), cerca de 800 a 1000 ou mais horas/pessoa, dependendo da
amplitude e profundidade do processo [29].
1.1.3 REUTILIZAÇÃO DE PROCESSOS X FRAMEWORKS/PATTERNS
Para que os processos sejam mais reutilizáveis, organizações precisam expressar
elementos comuns e variáveis dentro de um processo. Frameworks fornecem um
mecanismo para obter esta reutilização [29] [34] e são bem apropriados para domínios
onde várias aplicações similares são construídas várias vezes, partindo-se apenas de
idéias. Pesquisas voltadas para patterns [33] [36] também têm mostrado que eles são
ferramentas efetivas para a reutilização.
Embora um considerável número de frameworks tenha sido desenvolvido durante os
últimos anos (Huni 1995- em [47]), tem-se o conhecimento que projetar um framework
de alta qualidade ainda é uma tarefa difícil (Roberts 1996 e Taligent 199 em [47]).
Também existe uma série de problemas em aberto, quanto ao estudo de frameworks,
desde problemas no design, até sua instanciação e evolução [48]. Analogamente, é
importante salientar que para patterns também existem dificuldades [36]. O uso de
frameworks e patterns tem se dado em diversas áreas, entretanto seu uso para processos
ainda é pouco difundido. A aplicação ainda é realizada isoladamente, por exemplo [21],
[24], [26], [29] e [45], com uma definição não muito clara e precisa do que realmente são
frameworks e patterns para processos, e não contam com técnicas específicas para o seu
desenvolvimento. Associado a isto, existem dificuldades inerentes da atividade de definir
patterns e frameworks, como por exemplo fazer a análise do domínio.
Ainda sem a utilização de frameworks ou patterns, um exemplo [49] demonstrou a
dificuldade da reutilização de processos. Processos de requisitos foram disponibilizados
na web, para que empresas o reutilizassem, fazendo adaptações necessárias. O resultado
obtido foi que procedimentos (descrições detalhadas de como fazer algo) foram um dos
elementos menos reutilizados. Os autores possuem como hipóteses que i) “não fomos
capazes de fornecer detalhes suficientes do contexto no qual os procedimentos eram
15
usados, assim eles não puderam ser facilmente entendidos ou adaptados” e/ou ii) “não
havia guias de como adaptar e como modificar os procedimentos provenientes de uma
organização para outras”.
Hollenbach & Frakes [29] descrevem um método para criar processos reutilizáveis e suas
experiências usando-os em um ambiente industrial. Eles fornecem um framework
organizado em várias seções. No entanto, não identificam os pontos flexíveis ou comuns
do processo a ser reutilizado. Mesmo assim, conseguem alcançar bons níveis de
reutilização, demonstrando que é possível reduzir o tempo e esforço na definição dos
processos.
Este trabalho, baseando-se nos problemas e motivações citados, apresenta uma proposta
sistemática para a organização e descrição de processos, visando a reutilização. Sendo
assim, define-se uma arquitetura para a reutilização de processos. Esta arquitetura é
baseada em tipos de processos (standard, pattern e usual), em frameworks de processo, e
em diferentes tipos de linguagens de modelagem de processo, especificadas em XML –
Extensible Markup Language (Linguagem de Marcação Extensível) [50], para descrever
cada um dos tipos de processos. Com a finalidade de facilitar a reutilização e recuperação
de informações faz-se uso de facetas [38], guias de reutilização e utiliza-se process
patterns organizados e classificados em comunidade, família e indivíduo. Alguns
processos de engenharia de requisitos foram analisados para criar um framework de
processos e um protótipo de uma ferramenta foi desenvolvido para viabilizar um estudo
de caso para validar o uso da arquitetura proposta. Um estudo de caso foi realizado com
uma empresa do setor de informática com o objetivo de avaliar nossa proposta. Um
processo de engenharia de requisitos foi definido para um de seus projetos, a partir da
reutilização dos dados dos processos disponíveis na base de dados da ferramenta. Alunos
do curso de Engenharia de Requisitos da PUC também utilizaram a ferramenta de
reutilização de processos e avaliaram a viabilidade da proposta desta tese.
Neste trabalho, os modelos de processos gerados são genéricos e não tem a finalidade, a
princípio, de automação. Antes, são ferramentas para programas de melhoria de
16
processos, reutilização, treinamentos – quando da institucionalização de processos – e
documentação.
As atividades de pesquisas desenvolvidas no contexto desta tese podem ser observadas no
diagrama SADT que segue:
Figura 1- Diagrama SADT das atividades desta tese
DESCRIÇÃO DAS CONTRIBUIÇÕES
Reutilização de processos é um campo de pesquisa promissor, tendo em vista os custos na
definição e melhoria de processos. Os custos, por exemplo, referem-se a definição de
modelos para descrição de processos, entendimento de modelos e normas, descrição de
processos e construção, compra ou adaptação de ferramentas de processos.
Como forma de reduzir o tempo gasto na definição de processos elaborou-se uma
arquitetura para organizar e descrever processos. A arquitetura proposta integra diferentes
Literatura sobreprocessos e sua reutilização
Literatura sobre patterns Literatura sobre frameworks
Definir linguagempara modelagem
de processosCAP 4
.
Linguaguem p/ definir os tipos deprocessos/framework
Definir
p/ reutilizaçãoprocessos CAP 3
Modelos de características,hot-spot cards, modelo 3Cs
Arquitetura parareutilização deprocessos
Construir aferramenta
web CAP 6
Linguagem webXML
Ferramentaparareutilização deprocessos
Definir processos / framework paraeng. derequisitos
CAP 5
Conhecimentosobreeng. derequisitos
Diferentes tiposde processos p/
requisitos
Framework processode eng. derequisitos
arquitetura
eng. de
Conceitos sobrereutilização de componentes eprocessos
Realizar estudo de
casoCAP 7
Modelos de ProcessoXML/DTD
Dados dareutilização Validação da arquitetura
Literatura sobreprocessos e sua reutilização
Literatura sobre patterns Literatura sobre frameworks
Definir linguagempara modelagem
de processosCAP 4
.
Linguaguem p/ definir os tipos deprocessos/framework
Definir
p/ reutilizaçãoprocessos CAP 3
Modelos de características,hot-spot cards, modelo 3Cs
Arquitetura parareutilização deprocessos
Construir aferramenta
web CAP 6
Linguagem webXML
Ferramentaparareutilização deprocessos
Definir processos / framework paraeng. derequisitos
CAP 5
Conhecimentosobreeng. derequisitos
Diferentes tiposde processos p/
requisitos
Framework processode eng. derequisitos
arquitetura
eng. de
Conceitos sobrereutilização de componentes eprocessos
Realizar estudo de
casoCAP 7
Modelos de ProcessoXML/DTD
Dados dareutilização Validação da arquitetura
17
tipos de processos, em uma organização e descrição apropriadas, aplicando conceitos que
facilitam a reutilização (frameworks, patterns e tipos de processos). A utilização de um
framework também orienta a definição de processos e proporciona a reutilização. Sendo
assim, este trabalho tem como principais contribuições:
§ Uma arquitetura para reutilização de processos, integrando e organizando diferentes
conceitos (patterns, standards e frameworks) que viabilizam, de forma sistemática e
prática, a reutilização de processos.
§ Uma arquitetura que permite a obtenção de diferentes modelos de processos que
podem ser base para a geração de um processo padrão.
• O estabelecimento de uma base de dados inicial de processos para a área de
engenharia de requisitos que poderão ser reutilizados e adaptados, quando necessário.
§ Uma linguagem de modelagem de processos, mais estruturada que as linguagens
usuais e especificada em XML (Extensible Markup Language) obtendo-se uma
reutilização tanto de conteúdo, quanto de estrutura dos processos. Esta reutilização
provê uma fonte de informação flexível que pode ser facilmente modificada e
reorganizada.
§ Uma experiência na utilização de conceitos de frameworks de aplicação3 à
frameworks de processos.
§ A definição da estrutura de guias de reutilização, que são utilizados juntamente com
os frameworks de processo.
§ Um processo de análise de domínio de processos para a formulação de frameworks.
§ Um protótipo de uma ferramenta web que implementa a arquitetura proposta, dando
apoio a atividade de reutilização e permitindo a evolução da base de dados de
processos, juntamente com um esquema sistemático de organização e acesso à base
de dados de processos, permitindo uma melhor busca e seleção.
§ Um estudo de caso, relatando os resultados e fornecendo dados sobre a possibilidade
da reutilização de processos e o uso da arquitetura proposta.
3 Os frameworks que modelam um domínio da aplicação são denominados frameworks de aplicação [47].
18
ORGANIZAÇÃO DA TESE
O próximo capítulo descreve os conceitos básicos necessários para o entendimento desta
tese. Estes conceitos são: processo, reutilização de processos, frameworks (seu processo
de desenvolvimento e tipos), patterns, facetas e XML.
O capítulo 3 apresenta e descreve detalhadamente os elementos da arquitetura proposta,
ou seja, as linguagens de modelagem de processos, tipos de processos, frameworks de
processos, instâncias de processos e guias de reutilização.
O capítulo 4 descreve a linguagem de modelagem dos processos proposta e sua
especificação em XML.
O capítulo 5 disserta sobre o desenvolvimento do framework baseado na análise do
domínio de processos de engenharia de requisitos, seus pontos comuns e flexíveis e os
guias de reutilização. O capítulo 6 apresenta o processo de reutilização definido e as
funcionalidades básicas do protótipo da ferramenta proposta.
O capítulo 7 relata o estudo de caso utilizando a ferramenta na web e os resultados
obtidos e o capítulo 8 lista as conclusões do trabalho, suas contribuições em relação a
literatura e os pontos a serem pesquisados em trabalhos futuros.
RESUMO
Descreveu-se sobre a evolução das pesquisas em processos de software, de uma ênfase
em produto para ênfase em processo e os principais tópicos de estudo. Dentre os tópicos,
reutilização de processos ainda não obteve destaque. A quantidade de tempo e custo alto
da definição de processos devido entre outros, aos problemas com a maturidade das
organizações, têm motivado pesquisas em como se obter processos reutilizáveis.
Frameworks e patterns têm se mostrado ferramentas úteis na reutilização, no entanto
ainda existem muitos problemas a serem tratados nesta área e não se tem uma definição
clara de como isto é aplicado a processo. Mesmo com todos esses problemas, acredita-se
que reutilização ainda é uma das áreas mais promissoras e percebe-se uma lacuna nas
pesquisas relacionadas com a reutilização de processos. Portanto, propõe-se uma
arquitetura como uma proposta sistemática para a organização e descrição de processos,
visando a reutilização.
19
Capítulo 2 – Conceitos Básicos
Este capítulo define os conceitos básicos para o entendimento da tese. Primeiramente, define-se
o que se entende por processo de software e sua reutilização e descreve-se o que são
frameworks, seu processo de desenvolvimento e tipos. Em seguida, apresentam-se as
definições de patterns e seus relacionamentos com frameworks. Como elementos para facilitar a
recuperação de informações, as facetas são apresentadas. Finalmente, descreve-se XML, a
meta-linguagem escolhida para definir e formalizar a linguagem para modelagem de processos.
PROCESSOS
Neste item “Processos” descreve-se, fundamentalmente, um resumo sobre processos
extraído do artigo “Software Process: A Roadmap” de Alfonso Fuggetta [97] e do
histórico definido no site GPDA – Graphical Design Process Assistant
(http://www.informatik.uni-bremen.de/uniform/vm97/home.htm) [70].
Uma das principais direções adotadas por pesquisadores e praticantes, na área de
processos, está centrada no estudo e melhoria de processos que produzem software. Estes
estudos partem da definição que existe uma correlação direta entre a qualidade do
processo e a qualidade do software produzido [97]. A área de pesquisa que trata destas
questões é denominada usando o termo software process (processo de software).
A noção de processo de software define-se tendo como base o conceito de ciclo de vida e
fornece um amplo e compreensivo conceito para moldar e organizar os diferentes fatores
e questões relacionadas às atividades de desenvolvimento de software. Um ciclo de vida
define os diferentes estágios no tempo de vida de um produto de software, ele define os
principios e diretrizes de acordo com os diferentes estágios, entretanto ele não prescreve
um curso preciso de ações, um organização, ferramentas e procedimentos operacionais,
restrições e políticas de desenvolvimento.
Existem várias definições de processos de software, a adotada nesta tese é a definida por
Fuggetta [97]:
20
Um conjunto coerente de políticas, estruturas organizacionais, tecnologias,
procedimentos e artefatos que são necessários para conceber, desenvolver, entregar e
manter um produto de software.
Sendo assim, um processo de software explora um número de contribuições e conceitos,
como por exemplo tecnologias de desenvolvimento de software (suporte tecnológico
usado no processo, métodos e técnicas de desenvolvimento de software (diretrizes de
como usar tecnologia e acompanhar atividades de desenvolvimento de software),
comportamento organizacional (a ciência de organizações e pessoas), marketing e
economia.
Segundo Fuggetta [97], visualizando o desenvolvimento de software como um processo
tem ajudado significantemente a identificar as diferentes dimensões do desenvolvimento
de software e os problemas que precisam ser abordados para estabelecer práticas efetivas.
Introduzir ferramentas e ambientes efetivos não é suficiente; é preciso prestar atenção na
inter-relação complexa de um número de fatores organizacionais, culturais, tecnológicos
e econômicos que interagem sobre os processos.
Em seu artigo “Software Process: a Roadmap” Fuggetta apresenta e discute os principais
resultados que a pesquisa de processo de software atingiu na década passada. Comenta
sobre as pesquisas de suporte e modelagem de processos, melhoria de processos, métricas
e estudos empíricos, processos propriamente ditos e salienta que existe muito trabalho a
ser realizado. Outros artigos também relatam os resultados atingidos nesta área [99],
[100] e [101].
A melhoria do processo de desenvolvimento é certamente uma das prioridades da
indústria de TI. O software tem se tornado o componente mais crítico em qualquer
produto ou serviço moderno. Um número de avaliações de processos e técnicas de
melhoria tem sido propostos e aplicados em um significante número de casos, entretanto
a avaliação dos efeitos produzidos pelos modelos e métodos de melhoria e avaliação
21
geram controvérsias entre pesquisadores e praticantes, em particular quanto as mudanças
na performance da empresa [98]. A revista Software Process: Improvement and Practice
[102] é dedicada a abordar assuntos diretamente relacionados a processos, melhorias e
suas práticas.
Em um trabalho de definição e melhoria de processos as descrições são fundamentais,
pois elas registram o conhecimento da organização. Entretanto, as descrições de
processos variam de uma granularidade fina para uma granularidade maior (alto nível).
Processos que devem ser automatizados e que são críticos geralmente necessitam estar
em um nível de granularidade mais fino, ser bem detalhados, permitindo a
implementação e a execução em seus detalhes. Processos pequenos e simples também
podem ser detalhados em uma granularidade fina. Por outro lado, processos que servem
de guias, em geral, possuem suas descrições num nível mais alto – são mais genéricos.
Neste trabalho, a ênfase são estes processos genéricos, não se preocupando com seus
aspectos dinâmicos e de execução.
Encontrar o nível de descrição perfeito para processos é um desafio. Adota-se, então,
descrevê-los nos níveis de processo e atividade – segundo nossas pesquisas anteriores
[52] [53] (com adaptações), e experiência prática [54]. O nível processo fornece, entre
outros, sua visão geral, seus objetivos e descrição. O nível atividades possui um nível de
atividades macro e um nível de atividades detalhado. Pela nossa experiência em definição
de processos, estes níveis são satisfatórios para um bom entendimento e base para sua
execução. Quando se tem um nível, se tem apenas uma noção do processo, dificultando o
entendimento e execução. Quando se tem dois níveis, já se tem uma noção das atividades,
mas estas ainda estão em um nível macro, não descrevendo algumas detalhes
importantes. Com três níveis é possível descrever os detalhes necessários para realizar a
execução de uma atividade sem ter uma documentação exaustiva.
22
REUTILIZAÇÃO DE PROCESSOS
O conceito básico de reutilização de software sistemática segundo McIlroy, 1969 [55] é:
desenvolver componentes de sistemas de um tamanho razoável e reutilizá-los. Segundo
Jacobson [37] reutilização sistemática é a criação, gerenciamento, suporte e
reaproveitamento propositado de ativos (assets). Esta idéia, inicialmente aplicada na
codificação, estendeu-se a outros produtos relacionados a especificação e design, teste e
recentemente, para processos.
Baseado no conceito de Hollenbach & Frakes [29], onde reutilização de processos é o uso
de uma descrição de processo na criação de outra descrição de processo, adotamos o
seguinte conceito:
Reutilização de processo é o uso de um modelo de processo, na criação de outro
processo.
Um modelo de processo é uma descrição de um processo expresso em uma linguagem de
modelagem de processos. Adotamos um conceito mais amplo referindo-se, além do
conteúdo, também a reutilização da “estrutura” (modelo) expressa pela linguagem.
A seguir descrevemos os dois principais trabalhos relacionados com a reutilização de
processos.
O artigo de Craig Hollenbach e Willian Frakes [29] é um dos mais importantes, pois
define um ciclo de vida de uma descrição de processo, um método para definir processos
reutilizáveis e um método para adaptar estes processos. Eles também relatam a
experiência deles usando os métodos em um ambiente industrial. Eles comentam que os
trabalhos de base (groundwork) com reutilização de processos existem. Citam trabalhos
como o de Castano [27] que é relacionado com a abstração de objetos comuns a partir de
um conjunto de definições de processos orientados a objetos; e as pesquisas do DoD no
projeto STARS [103]; do Software Engineering Institute [104] e do Software
Productivity Consortium [105] que têm produzido um conjunto de notações e métodos
para definição de processos. Também mencionam que grandes empresas americanas
demonstram instancias de reutilização de processos e que outra empresas têm
23
desenvolvido ferramentas de execução de processos, tais como Process Weaver [106],
Synervision [107] e PEAKS [108].
Hollenbach e Frakes utilizam o modelo 3Cs [72] (conceito – semântica, conteúdo –
implementação e contexto – ambiente necessário) aplicado para a reutilização de
componentes de software para organizar dados dos processos, tendo-se então:
• Conceito: uma especificação informal da informação geral do processo, descrição
do Cliente e a descrição da interface.
• Conteúdo: inclui a descrição dos procedimentos do processo utilizando a
representação gráfica e textual.
• Contexto: uma descrição sobre o domínio, a organização e o projeto no qual o
processo está inserido e será executado e o custo, benefício e riscos
(gerenciamento) do processo.
Eles relatam que a finalidade de uma metodologia para a definição de processos é criar
processos reutilizáveis tal que projetos dentro de uma organização possam adaptá-los, a
um custo efetivo, aos seus requisitos. Portanto, definem um ciclo de vida para a descrição
de processos. Este ciclo de vida possui os seguintes passos:
• Definir o processo reutilizável: é definir um processo propriamente dito e garantir
que eles realmente possam ser reutilizados.
• Desenvolver treinamento para o processo reutilizável: definir treinamento.
• Adaptar o processo reutilizável ao projeto: adaptar o projeto para atender as
necessidades específicas do(s) projeto(s) que irá(ão) utilizá-lo.
• Adaptar o treinamento do processo reutilizável para o processo adapatado ao
projeto: adaptar o treinamento para as necessidades do projeto que utilizará o
processo.
• Executar o processo no projeto: significa que o projeto passa a utilizar na prática
o processo. Acompanhamento de garantia de qualidade e medições devem ser
realizadas.
• Refinar o processo: baseado nas medições e nos passos anteriores o processo deve
ser avalidado para verificar se ele atingiu seus objetivos ou não. Caso não tenha
24
atingido, uma análise é realizada, a definição do processo é refinada e treinamento
e execução são realizados novamente.
O método estabelecido para a definição de processos reutilizáveis possui os seguintes
passos:
• Análise dos requisitos do processo: define as condições sobre as quais o processo
será executado e as metas e os requisitos que o processo irá satisfazer.
• Análise do processo: refere-se a uma análise de processos específicos de projetos
e de dados relevantes de processos da indústria.
• Design preliminar do processo: neste momento são definidas as descrições dos
processos, por exemplo, seus clientes, entradas, saídas e indicadores e as
interfaces com outros processos.
• Design detalhado do proceso: este passo define o conteúdo do processo ou os
procedimentos. Isto inclui métodos/ procedimentos, papéis, indicadores de
processo, feedback e mecanismos de controle.
• Codificação do processo e teste unitário: após o processo ser definido ele será
automatizado totalmente ou parcialmente.
• Teste e integração de processo: este passo garante que o processo definido possa
encontrar as metas de produto e processo.
Além do processo de definição Hollenbach e Frakes também definiram um método para a
adaptação de processos.
Scott Henninger [43] descreve um ambiente para reutilização de processos. Ele descreve
um método que envolve informação reutilizável em um modelo de processo que é
customizado para as necessidades específicas dos projetos. A proposta utiliza um sistema
baseado em regras para adaptar o processo de software para as necessidades específicas
de projetos individuais, e usa técnicas de aprendizado organizacional para modificar e
atender as necessidades da organização. Ele afirma que o objetivo torna-se maior que a
reutilização dos processos, pois também dissemina as melhores práticas através do
25
processo de desenvolvimento, o qual fornece a fundamentação para a melhoria contínua
dos processos e qualidade.
A proposta de Henninger inicia com uma metodologia de desenvolvimento padrão
(MDP) que especifica um conjunto de processos projetados para atender a uma ampla
variedade de necessidades de projetos específicos. A MDP, que age como um esquema
de processos é então adaptada para atender as necessidades de esforços de
desenvolvimento específicos. O resultado é um processo customizado instanciado a partir
de um esquema. Novos projetos reutilizam os processos existentes e ficam livres para
reutilizar quaisquer artefatos associados com elementos de processo, incluindo código
fonte reutilizável, documentação, modelos de dados, diretrizes e outras informações
relevantes. A proposta também define um processo de desvio formal que modifica o
esquema para atender a evolução das necessidades da organização.
FRAMEWORKS
Para um melhor entendimento, organiza-se este item em três tópicos: definição de
frameworks, como desenvolver frameworks e tipos de frameworks. As definições, aqui
apresentadas, estão voltadas para frameworks de aplicação e orientação a objetos. Sendo
assim, a definição de frameworks de processo é somente apresentada no Capítulo 3. No
Capítulo 3, quando se descreve a arquitetura para processos desenvolvida nesse trabalho,
procura-se utilizar a “idéia” dos frameworks de aplicação, visto que processos estão em
um nível de abstração muito diferente que frameworks de aplicação, os quais são
implementados como programas.
2.1.1 DEFINIÇÃO DE FRAMEWORKS
Embora o primeiro framework amplamente utilizado tenha sido no final dos anos 70
(framework de interface de usuário Smalltalk-80), as suas definições ainda variam, mas
muitas vezes se complementam e geralmente têm como base o uso da orientação a
objetos. Citam-se algumas definições encontradas na literatura, em [47] e [48]:
26
§ Segundo Pree (em [48]): “framework é uma coleção de diversos componentes4
independentes com uma cooperação pré-definida entre eles, com a finalidade de
realizar uma determinada tarefa”.
§ Segundo Johnson (em [47]): “um framework é um design reutilizável de todo (ou
parte de) um sistema de software, representado por um conjunto de classes abstratas e
pela maneira como suas instâncias interagem” (descreve a estrutura de um
framework).
§ Segundo Fayad et all [47]: “um framework é o esqueleto de uma aplicação que pode
ser customizada por um desenvolvedor da aplicação” (descreve a finalidade de um
framework).
§ Segundo Johnson-Foote (em [47]): “framework é uma aplicação semi-completa e
reutilizável que pode ser especializada para produzir aplicações customizadas”.
§ Segundo Parnas (em [47]): “um framework modela o comportamento de uma família
de aplicações”.
§ Segundo Fayad et all [47]: “um framework define uma linguagem de alto nível com a
qual aplicações dentro de um domínio são criadas através da especialização
(adaptação)”. Segundo Pree [34] a especialização é definida pelos pontos de
flexibilização – chamados hot-spots
Os Frameworks [34] têm atraído a atenção de muitos pesquisadores e engenheiros de
software e sido aplicados para uma grande variedade de domínios. As principais
vantagens de frameworks incluem reutilização e redução do tempo para disponibilizar
aplicações no mercado [47].
Os frameworks de aplicação devem apresentar uma parte que é comum entre as
aplicações que foram utilizadas de base para criá-lo. Uma importante característica é que
eles devem ser flexíveis, ou seja, devem ser adaptáveis de acordo com os requisitos
específicos de um determinado domínio. Os aspectos de um domínio de aplicação que
4 Componentes são blocos de construção semi-acabados e prontos para uso. A reutilização de um
framework geralmente implica em adaptar blocos de construção a necessidades específicas, por exemplo,
redefinindo métodos de algumas classes do framework em suas subclasses.
27
têm que se manterem flexíveis, para proporcionar a especialização, atendendo às
necessidades específicas das aplicações, são conhecidos como pontos de flexibilização do
framework (hot-spots) [34]. Escolher adequadamente os hot-spots influi diretamente na
qualidade do framework. Portanto, eles devem estar identificados de forma explícita no
framework.
Os pontos de flexibilização são deixados incompletos e cada vez que o framework é
utilizado (instanciado) eles podem ser substituídos por uma implementação diferente.
Entretanto, segundo Fontoura [48] a instanciação é muito mais complexa do que
simplesmente agregar componentes aos hot-spots. Os hot-spots, por exemplo, podem
possuir interdependências, e podem ser opcionais e os frameworks podem fornecer
diversas maneiras de acrescentar a mesma funcionalidade e assim por diante.
Embora seja complexa, o desenvolvedor da aplicação ainda pode preocupar-se muito
mais com as peculiaridades da aplicação que está sendo construída com o uso do
framework, do que com os detalhes para iniciar uma nova aplicação, uma vez que ele tem
predefinida a arquitetura global, isto é, a composição e a interação dos seus componentes.
Os frameworks descrevem tanto objetos componentes quanto de que forma estes objetos
interagem. Eles descrevem a interface de cada objeto e o fluxo de controle entre eles.
Com estas interfaces torna-se possível misturar e casar (mix and match) componentes e
construir uma ampla variedade de sistemas a partir de um pequeno número de
componentes. Numa visão orientada a objetos, as classes abstratas determinam os
aspectos comuns do framework e as classes concretas derivadas representam uma das
instâncias dos aspectos variáveis.
Sendo assim, um framework, como uma aplicação genérica, encapsula tanto um design
abstrato, que é comum para todas as aplicações do domínio do framework, quanto hot-
spots que permitem que o framework seja customizado para aplicações com requisitos
específicos [47]. Cada hot-spot incorpora um aspecto variável específico, como por
exemplo um conjunto com diferentes representações. Quando uma aplicação é criada a
partir de um framework, liga-se um hot-spot para uma ou várias das diferentes instâncias
da sua variabilidade, ou seja, para uma das suas alternativas de implementação. Isto pode
28
ser realizado durante a criação da aplicação, a partir do framework, ou pelo usuário final
em tempo de execução da aplicação.
Os frameworks geralmente são implementados como programas orientados a objetos
genéricos, a fim de possibilitar a sua adaptação a várias aplicações. Idéias comuns
tornam-se classes abstratas, objetos são parametrizados para serem reutilizáveis e a
herança é utilizada para organizar a biblioteca de classes [48].
2.1.2 COMO DESENVOLVER FRAMEWORKS
Não sendo o objetivo comparar processos de desenvolvimento de frameworks, mas ter
uma noção de suas atividades, apresentamos o processo de Pree [34] em mais detalhes e
sumariza-se outros dois [47] [48]. O processo de Pree está descrito com base em [47] e
[48].
Primeiramente, o processo de desenvolvimento de frameworks difere do desenvolvimento
de aplicações padrão uma vez que uma etapa extra – a etapa de instanciação – é
necessária para completar os hot-spots, fornecendo o comportamento específico
necessário para as instâncias do framework [em 48].
Pree [34] dá ênfase na descrição geral de um processo de desenvolvimento de um
framework, considerando a identificação de seus pontos de flexibilização e a utilização de
patterns como forma de contribuir para uma diminuição do número de ciclos de iteração
necessários (Figura 2). Pree considera esta identificação dos pontos de flexibilização
como uma necessidade às metodologias existentes de análise e projeto orientados a
objeto. O ciclo expressa o processo de evolução típico de um framework. A seguir,
apresentam-se as etapas do processo de desenvolvimento de frameworks definido por
Pree.
29
Identificar “Hot-Spots”Especialista do Domínio, Engenheiro de Software
“Hot-Spots”OK?
S
N
aplicação dedesign patterns
(Re)Projetar FrameworkEngenheiro de Software
Adaptar FrameworkEspecialista do Domínio, Engenheiro de Software
Definir Modelo de Objetos do DomínioEspecialista do Domínio, Engenheiro de Software
Figura 2 – Processo de desenvolvimento de um framework – Pree [34]
Definir o Modelo de Objetos do Domínio: para definir o modelo de objetos do domínio
recomenda-se que, com base em pelo menos dois modelos de objetos de aplicações
similares, se identifique características comuns entre eles. Assim, pode-se obter um
modelo de objetos único que reflita as propriedades das aplicações desse domínio. Deve-
se realizar uma análise do domínio e isto é uma atividade tipicamente iterativa. O
principal objetivo é identificar os principais elementos (objetos/classes) do framework, e
a forma como eles se relacionam. Cartões CRC – Class-Responsability-Collaboration, ou
seja, Classe-Responsabilidade-Colaboração (Beck 1989 e Wilkinson 96 em [47]) ajudam
na identificação inicial de objetos e suas associações.
Identificar Hot-spots: Uma vez que o modelo está definido é necessário identificar e
documentar os pontos de flexibilização (identificar hot spots). Estes são sensíveis às
mudanças do domínio. Algumas perguntas podem ser realizadas pelos especialistas do
domínio para auxiliar na identificação dos hot spots: “Que aspectos diferem de uma
aplicação para outra? Qual é o grau de flexibilidade desejado? Deve ser possível mudar o
comportamento flexível em tempo de execução?”. A identificação explícita por meio de
hot spot cards pode auxiliar na redução do número de iterações. Um cartão para pontos
de flexibilização – hot spot card (veja a Figura 3) – deve fornecer o nome do hot spot;
um termo conciso descrevendo a funcionalidade (deve corresponder aos métodos ou
responsabilidades), que deverá ser mantida flexível; e especificar a flexibilidade.
30
Cálculo do PreçoCálculo do PreçoEspecifique o grau de flexibilidade:( X) Adaptação com restart( ) Adaptação pelo usuário final
Cálculo do preço quando itens de aluguelsão retornados; o cálculo está baseadonos parâmetros específicos da aplicação
Sistema do hotelSistema do hotel: o cálculo resulta do preçodo quarto * número de noites + chamadasde telefone + consumo do barSistema de aluguel de carroSistema de aluguel de carro: o cálculo resulta do ...
Nome doHot-Spot
Descriçãogeral dasemântica
Comporta-mento dohot-spot empelo menosduassituações
Figura 3 – Hot spot Card – Fayad et all [47]
Pree reconhece que métodos de design OO negligenciam a identificação de hot-spots e
propõe o uso de cartões hot-spot como um meio para documentar a informação necessária
para desenvolver frameworks. Os cartões documentam a semântica de cada hot-spot. Eles
têm como objetivo capturar conhecimento do domínio para ajudar no desenvolvimento do
framework, e melhorar a comunicação entre os especialistas no domínio e os que
desenvolvem frameworks.
(Re) Projetar Framework: decidido quais são os pontos de flexibilização deve-se
modificar o modelo de objetos construído, a fim de fazer refletir a flexibilidade desejada
para o framework. Nesta etapa, design patterns de construção, também conhecidos como
metapatterns, podem auxiliar na especificação do framework. Metapatterns designam um
conjunto de design patterns que descrevem como construir frameworks independentes de
um domínio específico, e permitem diferentes níveis de flexibilidade combinando
conceitos básicos de orientação a objetos. Pree propõe o uso dos meta-patterns, como
meio de documentar hot spots durante o design .
Adaptar Framework: finalmente, após a reavaliação do projeto do framework, este deve
ser adaptado. Isto significa que o framework deve ser utilizado várias vezes com o
31
propósito de identificar hot-spots que são pouco apropriados ou que não foram
anteriormente identificados.
O design de framework é como o design de muitos software reutilizáveis (Krueger 1992,
Tracz 1995 in [47]). Para desenvolvê-lo são necessárias várias iterações. As razões para
as iterações são:
§ dificuldade na análise de domínio, quando o domínio não é maduro necessita várias
iterações;
§ a descoberta de erros posteriormente ao design, necessitando novas iterações;
§ frameworks são abstrações, assim o design do framework depende de exemplos
originais. Cada exemplo que é considerado torna o framework mais genérico,
reutilizável e caro. Mesmo com a melhor notação para descrever um framework,
pode ser necessário ter novas iterações. A única maneira de encontrar o que está
errado com um framework é ter muita experiência prática no domínio ou utilizá-lo na
prática.
Segundo Fayad et all [47] algumas questões devem ser consideradas no design de
frameworks. Eles sugerem os seguintes passos:
1. Faça o design de uma aplicação que pertença ao domínio do framework e generalize-a
apenas quando você entender o exemplo;
2. Não trabalhe em diferentes aspectos variáveis ao mesmo tempo, mas separe-os
claramente.
3. Capture e especifique exatamente o grau de variabilidade que são necessários, antes
de definir a solução de como você vai fornecê-las.
Baseados em suas experiências, desenvolveram uma proposta para fazer o design de
frameworks, que seguem as regras acima. Eles consideram que o design de frameworks é
um problema de generalização. Tendo isto como base iniciam de uma estrutura de classe
definida, que modela uma aplicação escolhida de um domínio definido e transformam
isto por uma sequência de transformações de generalização. Cada uma das
32
transformações introduz um hot-spot dentro da estrutura de classe. A Figura 4 mostra as
atividades do design do framework.
Criar Modelo de Classes da Aplicação Definida(Atividade Modelar a aplicação)
Análise Alto-Nível dos Hot-Spots(Atividade Especificar e Analisar Hot-Spots - I)
Análise Detalhada e Especificação de Hot-Spots(Atividade Especificar e Analisar Hot-Spots - II)
Design Alto-Nível do Subsistema de Hot-Spots(Atividade Design Alto Nível dos Hot-Spots)
Transforme o Modelo de Classes por Generalização com o Subsistema Hot-Spot
(Atividade Transformação de Generalização)
Criar Modelo de Classes da Aplicação Definida(Atividade Modelar a aplicação)
Análise Alto-Nível dos Hot-Spots(Atividade Especificar e Analisar Hot-Spots - I)
Análise Detalhada e Especificação de Hot-Spots(Atividade Especificar e Analisar Hot-Spots - II)
Análise Detalhada e Especificação de Hot-Spots(Atividade Especificar e Analisar Hot-Spots - II)
Design Alto-Nível do Subsistema de Hot-Spots(Atividade Design Alto Nível dos Hot-Spots)
Design Alto-Nível do Subsistema de Hot-Spots(Atividade Design Alto Nível dos Hot-Spots)
Transforme o Modelo de Classes por Generalização com o Subsistema Hot-Spot
(Atividade Transformação de Generalização)
Figura 4 – Atividades do design do framework – Fayad et all [47]
Outro processo de desenvolvimento de framework, definido por Fontoura [48] pode ser
visualizado na Figura 5.
Papel
Artefato
Processo
Legenda:
Framework
Mudanças nodomínio
Framework
Application
Usuário
Designer Mantenedor
Implementador
Representaçãode design
Manutenção
Implementação
Instanciação
Conhecimentodo domínio
Design
Documentação
ApplicationApplicationApplicações
Figura 5 - Processo de desenvolvimento de frameworks – Fontoura [48]
Segundo Fontoura, cada tarefa diferente de desenvolvimento é designada para um cargo
diferente, por exemplo designer ou o implementador. O mesmo ator (e grupo de atores)
33
podem participar em diferentes cargos ao mesmo tempo em um projeto específico. O
“conhecimento de domínio” e “mudanças de domínio” representam artefatos que são
produzidos na etapa análise de domínio (não abordada pelo autor). Cada processo é
responsável pela transformação de um tipo de artefato: a fase de design cria o design do
framework; a fase de implementação gera o framework e a documentação correspondente
a partir do design; a fase de instanciação usa os artefatos produzidos na fase de
implementação para gerar aplicações baseadas no framework. Finalmente, a fase de
manutenção pode evoluir tanto o design quanto o próprio framework, uma vez que apoia
transformações de design e implementação. Todas estas transformações podem ter que
ser apoiadas por atores humanos, já que informações talvez tenham que ser fornecidas.
Embora se tenha um processo, segundo Fayad et all [47] “nem metodologia nem técnicas
de design ajudarão a evitar o processo de aprendizado doloroso daqueles que desejam
trabalhar com frameworks”.
2.1.3 TIPOS DE FRAMEWORKS
Os frameworks podem ser classificados como “caixas-brancas” ou “caixas-pretas”,
segundo Johnson91, Johnson97b, Pree96 em [47]:
Os frameworks “caixas-brancas”, se caracterizam pelo fato dos programadores
aplicarem a herança para estender as classes do framework. Os programadores precisam
entender o design e implementação do framework para utilizá-lo. Por isto geralmente são
mais difíceis de aprender a usar. Eles consistem de diversas classes incompletas,
adaptadas às particularidades de uma aplicação específica pela adição de atributos e
métodos a subclasses de uma ou mais classes do framework. Métodos sem
implementações default significativas devem ser redefinidos nas subclasses. Este
comportamento é alcançado através do mecanismo de herança, resultando em uma série
de novas subclasses.
Os frameworks projetados como “caixas-pretas” oferecem classes prontas para serem
usadas, um conjunto pré-fabricado de componentes (classes), que fornecem o
34
comportamento específico da aplicação. O desenvolvedor seleciona a partir deste
conjunto uma ou mais alternativas que modelem a aplicação e cujas adaptações nas
classes podem ser feitas por composição ou por instanciação parametrizada das classes. O
usuário precisa entender apenas a interface externa das classes, para poder adaptá-las às
aplicações. Estas adaptações podem ser feitas sem que haja modificações de
comportamentos por meio de herança. Uma forma de adaptação desses tipos de
componentes é através da instanciação parametrizada (configuração) das suas classes.
Apesar dos frameworks “caixas-pretas” serem mais fáceis de aprender a usar, eles são
menos flexíveis do que os projetados como “caixas-brancas”. Frameworks não são nem
puramente “caixas-brancas” nem puramente “caixas-pretas”, embora a tendência seja que
cada vez mais frameworks sejam projetados internamente com componentes “caixas-
pretas”.
PATTERNS
A grande difusão de patterns, na engenharia de software, se deu com Gamma95 et all.
[33] abordando design patterns que são soluções genéricas para problemas recorrentes.
Os patterns podem ser usados para ajudar o desenvolvimento de frameworks [34].
Patterns tratam problemas no processo de desenvolvimento de software [56], variando
desde, análise de domínio do problema, [57], processos (process patterns) [58], questões
organizacionais (organizational patterns) [58] – como gerenciamento de projeto e
organização da equipe – à questões de implementação (design patterns) [33],
considerando uma linguagem de programação particular. Segundo Rising [59] “nós
podemos capturar os patterns básicos de projetos de sucesso e usá-los para estabelecer
práticas e estruturas organizacionais que podem melhorar as chances de sucesso em uma
nova organização de software”.
Como frameworks e a grande maioria dos patterns tem a finalidade de prover
mecanismos de flexibilidade e extensibilidade a sistemas, é comum ficar em dúvida se
frameworks e design patterns diferem ou não. Os pontos a seguir ajudam a clarear as
diferenças [33]:
35
§ frameworks são implementados em uma linguagem de programação e, nesse sentido,
são mais concretos que design patterns;
§ design patterns são elementos arquiteturais menores que frameworks e, geralmente,
os frameworks reutilizam vários deles em seus projetos, mas a recíproca não é
verdadeira;
§ design patterns são menos especializados que frameworks, sendo geralmente
independentes do domínio.
FACETAS
Um dos problemas essenciais em reutilização de componentes de software é a sua
localização e recuperação, a partir de uma grande coleção [38].
Muitas propostas para classificação e recuperação de software propõem um esquema de
classificação para catalogar componentes em uma base de software. Os esquemas
especificam alguns atributos, chamados facetas, para serem utilizados como descritores
de um componente de software, muitos deles focando na ação que o componente realiza e
nos objetos manipulados pelo componente. Tanto a classificação quanto a recuperação
são realizadas especificando-se termos para cada atributo (faceta) no esquema.
Relacionamentos com termos ou frases são expressas através da combinação de atributos,
permitindo então uma melhor precisão nas buscas [60].
Prieto-Díaz [38] propõe um esquema de classificação por facetas, para catalogar
componentes de software, pois acredita que os componentes podem ser descritos pelas
funções que realizam, como as fazem e seus detalhes de implementação. Facetas são
consideradas como perspectivas, ponto de vistas ou dimensões de um domínio particular.
Os elementos ou classes que compõem uma faceta são denominados termos. O esquema
proposto consiste de quatro facetas: a função desempenhada pelo componente, o objeto
manipulado pela função, a estrutura de dados onde a função realizou (meio ou
localização) e o sistema para o qual a função pertence. A Figura 6 ilustra um exemplo do
esquema de classificação por facetas para os comandos do Sistema Operacional Unix e
suas ferramentas.
36
Para evitar a duplicidade e descritores ambíguos, um vocabulário é utilizado, onde cada
termo tem um conjunto de sinônimos referentes. Outra característica deste esquema de
classificação é a utilização de um gráfico conceitual para medir a proximidade entre
termos em uma faceta.
FUNÇÃO OBJETO MEIO SISTEMA
GetPutCheckSearchMakeStartAddAppend
CharacterNumberExpressionLineStringIdentifieres
BufferTreeTableFileArchive
Line-editorText-formatter
ESQUEMA DE CLASSIFICAÇÃO POR FACETASDOMÍNIO - UNIX
Facetas
Termos
Termo Sinônimo
Add increment/ total/ sum
Figura 6 – Exemplo do esquema de classificação por facetas - Prieto-Díaz [38]
Os catálogos de componentes são construídos manualmente e a recuperação é realizada
especificando palavras-chave para cada faceta no esquema, a partir do vocabulário
controlado. Os componentes recuperados são armazenados de acordo com um valor
similar que é determinado através do gráfico de distância conceitual.
No escopo desta tese, visto que a base de um processo são suas atividades, adotam-se
apenas as facetas necessárias para descrever a função (chama-se ação) e objeto
manipulado. Faz-se uso, também, de um vocabulário com sinônimos e descarta-se a idéia
de utilizar o gráfico conceitual, visto o pouco ganho que isto acrescentaria ao trabalho. Os
próprios autores reconhecem que os gráficos tomam muito tempo, pois são definidos com
base na experiência, intuição e bom senso [38].
XML – EXTENSIBLE MARKUP LANGUAGE
O padrão XML (Linguagem de Marcação Extensível) é um subconjunto do padrão
internacional de processamento de texto SGML (Standard Generalized Markup
Language [ISO 8879]). O XML especifica uma meta-linguagem de marcação que
permite representar estruturalmente diversas informações que podem ser enviadas e/ou
recebidas e processadas na web de forma uniforme. Ele descreve uma classe de objetos de
37
dados chamado Documentos XML. Entretanto, XML especifica apenas o conteúdo e a
estrutura de um documento. A apresentação do documento é definida utilizando a
linguagem de folha de estilo extensível – XSL (Extensible Stylesheet Language) [61]. A
seguir resumem-se algumas informações a respeito do XML, provenientes de várias
fontes como [50], [62], [63] e [64].
Origens
O XML foi desenvolvido em 1996, por um grupo de trabalho chamado XML Working
Group, originalmente conhecido como SGML Editorial Review Board, sob o patrocínio
do World Wide Web Consortium – W3C. O objetivo do W3C era tornar o XML uma
simplificação do SGML (SGML86), tendo que apresentar o mesmo poder e generalidade
do SGML, entretanto sendo mais simples e apropriado para a utilização na WEB. Como
resultado, em 1998 o W3C, lançou o padrão XML como recomendação, [50].
Objetivos
Os objetivos do padrão XML são:
§ Ser fortemente utilizado na Internet;
§ Dar suporte a uma grande variedade de aplicações;
§ Ser compatível com SGML;
§ Possibilitar uma fácil codificação dos programas que processem documentos XML;
§ Possuir um número mínimo de características opcionais, preferencialmente zero.
§ Ter documentos XML legíveis pelo usuário e razoavelmente claros;
§ Possibilitar que projetos em XML sejam formais, concisos e de rápida elaboração;
§ Possibilitar a criação de documentos XML com facilidade.
XML x Outros Produtos
Os documentos XML possuem texto e tags identificando estruturas com o texto, assim
como em HTML. Por exemplo, “<Título> Sumário </Titulo>”. Entretanto em HTML não
é possível customizar tags e atributos. Mas isto é possível fazer em SGML. No entanto, o
XML é mais simples e tecnicamente menos complexo que o SGML. Embora XML
supere as limitações do HTML ele possui uma estrutura mais rígida do que HTML.
38
Benefícios
Além de possibilitar a reutilização das estruturas (gramática) e a criação de apresentações
diferentes para o mesmo documento, o XML fornece uma visão estruturada dos dados,
possibilita a integração de dados estruturados de muitas fontes diferentes, descreve dados
de uma grande variedade de aplicações e, permite que autores definam os seus próprios
conjuntos de tags.
O documento XML
Cada documento XML possui uma estrutura lógica e uma estrutura física. Fisicamente, o
documento é composto de unidades de armazenamento, denominadas entidades, que
podem ser internas (armazenadas no mesmo documento) ou externas (armazenadas
fisicamente em separado). As entidades possuem dados que são analisados
gramaticalmente (parsed) e que não são (unparsed). Dados que são analisados incluem
caracteres, sendo que muitos formam strings e outros formam marcações. Uma marcação
encapsula uma descrição da estrutura lógica e layout de armazenamento de documentos.
O XML fornece um mecanismo, a DTD – Definição do Tipo de Documento, para impor
restrições na estrutura lógica e layout de armazenamento. Tratando-se da estrutura lógica,
um documento XML é composto de marcações. Uma marcação, por exemplo, pode ser
uma declaração de um tipo de elemento, uma declaração de uma lista de atributos ou uma
declaração de uma entidade.
Documento XML Definição do Tipo de
Documento - DTD
4 2 Estrutura Lógica
Restrições para as estruturas
+ (Gramática) Estrutura Física
Figura 7 – O XML
39
Documentos XML, geralmente, iniciam com uma declaração XML que é uma instrução
de processamento usada para informar ao processador que o documento que será
analisado é do tipo XML. Se for usada deve ser a primeira marcação do documento.
Exemplo: <?xml version=“1.0” ? >
O número da versão é indicado para futuras extensões da linguagem.
Comentários “<!-- comentário -->” podem aparecer em qualquer lugar, depois da
declaração XML, ser de qualquer tamanho e conter qualquer conjunto de dados, exceto
“--”.
Cada documento XML contém um ou mais elementos. Cada elemento tem um tipo,
identificado pelo nome, como se fosse um identificador genérico, e pode ter um conjunto
de especificações de atributos.
Todo o elemento que não for vazio é marcado por um start-tag “<nome_elemento>” e
end-tag “</nome_elemento>”. O texto entre start-tag e end-tag é chamado conteúdo do
elemento. Tem-se então “<nome_elemento> conteúdo_do_elemento </nome_elemento>.
Um elemento vazio (EMPTY) contém apenas atributos e precisa apenas da empty-
element tag que inicia com “<” e termina com “/>”, como em “<nome_elemento_vazio
atributos/>”.
Um documento possui elementos, por exemplo título, subtítulo e rodapé. Utiliza-se a
declaração do tipo de elemento (!ELEMENT) para definir as regras para os tipos e
número de elementos que podem aparecer em um documento XML, que elementos
podem aparecer um dentro de outro, e em que ordem precisam aparecer. Através dos
elementos uma estrutura hierárquica de um documento é estabelecida. Todos os tipos de
elementos precisam ser definidos na DTD. Um elemento possui um conteúdo. Este
conteúdo pode ser vazio (EMPTY), qualquer conteúdo (ANY), um elemento que está
contido em outro (Elemento Filho – children element) e uma mistura de elementos filho e
texto (#PCDATA).
40
O exemplo a seguir, mostra um documento XML válido, contendo uma declaração XML,
comentários, uma definição do tipo de documento e o elemento raiz.
<?xml version="1.0"?> <!-- primeiro colocou-se a declaracao xml e a seguir tem-se a declaracao do tipo de documento mensagem --> <!DOCTYPE mensagem [ <!ELEMENT mensagem (#PCDATA)> <!--A seguir fecha-se a declaracao do tipo de documento --> ]> <!-- mensagem eh o elemento raiz --> <mensagem>Parabens voce finalizou com sucesso</mensagem>
No exemplo, verifica-se que na definição do tipo de documento (DOCTYPE) encontra-se
a especificação (no exemplo nome – mensagem – e tipo - #PCDATA) dos elementos
daquele documento (!ELEMENT ...).
Um documento XML pode ser válido ou bem definido. Ele só é válido se tiver uma
definição do tipo de documento (DTD) associada (ver próximo item). Para ele ser bem
definido não precisa estar associado a uma gramática (DTD), mas precisa ser estruturado
e satisfazer as seguintes restrições, segundo o W3C [50]:
• o documento deve começar com a declaração XML (“<?xml version=“1.0”?>”);
• cada uma das entidades analisadas que são referenciadas, direta ou indiretamente,
dentro do documento devem ser entidades bem definidas
• todos os elementos devem estar contidos dentro de um elemento raiz;
• todos os elementos devem estar devidamente aninhados;
• todos os elementos não vazios devem ter start-tag e end-tag
Veja, na Figura 8, um exemplo de um documento XML:
<?xml version=“1.0”?><nome_processo> Eng. Requisitos </nome_processo>
<?xml version=“1.0”?><!DOCTYPE processo [<!ELEMENT nome_processo (#PCDATA)>]><nome_processo> Eng. Requisitos </nome_processo>
A B
Figura 8 – Exemplo de documento bem definido (A) e um documento válido (B)
41
A Declaração do Tipo de Documento – DTD
Uma DTD contém ou aponta para marcações declarativas que definem uma gramática ou
conjunto de regras para uma classe de documentos. Assim, uma DTD especifica a
seqüência e aninhamento de elementos exigidos ou permitidos (nomes dos elementos e a
natureza de seu conteúdo), os valores e tipos dos atributos exigidos ou permitidos e os
nomes de entidades internas e entidades externas necessárias. Esta gramática definida
informa ao software como processar um documento XML, permitindo que ele seja
validado. Uma DTD pode estar diretamente dentro de um documento XML (figura 8 – B
– “<!DOCTYPE ...]>”) ou pode ser uma referência para uma entidade externa, sendo
outra unidade de armazenamento (veja exemplo a seguir).
<!DOCTYPE processo [<!ELEMENT nome_processo (#PCDATA)>]>
<?xml version=“1.0”?><!DOCTYPE processo SYSTEM c:\xml\processo.dtd"-->
<nome_processo> Eng. Requisitos </nome_processo>
I – c:\xml\processo.dtd II – documento XML
O arquivo processo.dtd (que contém a gramática) está gravado no c:\xml\ (I). No quadro
II o documento XML faz referência a DTD processo.dtd através, do “SYSTEM
c:\xml\processo.dtd”.
Nesta tese, utilizamos os recursos do XML – a DTD – para definir a linguagem de
modelagem de processos. A XSL (veja a seguir) é utilizada para mostrar o conteúdo em
um browser na internet.
XSL – EXTENSIBLE STYLESHEET LANGUAGE
Para acrescentar qualquer informação de estilo, para apresentar o documento XML em
um browser, é preciso de um segundo documento, expresso em uma linguagem de folha
de estilo extensível – XSL [61].
O XSL é uma mistura de regras de casamento de padrões, um mecanismo de aplicação
de template (a template apply mechanism) e uma linguagem de programação imperativa.
Cada dado (conteúdo) do documento do XML pode ser “lido” e apresentado em um
browser com o auxílio de um documento XSL. Veja o exemplo a seguir.
42
DOCUMENTO XML – contém o conteúdo e faz referência ao arquivo “listadeprocessos.xsl” que
define a apresentação do documento.
<?xml version="1.0"?> <?xml-stylesheet href="listadeprocessos.xsl" type="text/xsl"?> <ListadeProcessos> <item> <nome_processo>Processo de Engenharia de Requisitos</nome_processo> <autor>Julio C.S.P. Leite</autor> <versao>1</versao> </item> <item> <nome_processo>Processo de Gerencia de Requisitos</nome_processo> <autor>Rational</autor> <versao>1.1</versao> </item> <item> <nome_processo>Processo de Definicao de Requisitos</nome_processo> <autor>John W. Brackett</autor> <versao>2</versao> </item> </ListadeProcessos> DOCUMENTO XSL – trata da apresentação do conteúdo definido acima.
<?xml version="1.0"?> <xsl:stylesheet xmlns:xsl="http://www.w3.org/TR/WD-xsl"> <xsl:template match="/"> <HTML> <HEAD> <TITLE>Sua Lista de Processos de Engenharia de Software</TITLE> </HEAD> <BODY> <H3>Lista de Processos - Engenharia de Requisitos:</H3> <TABLE BORDER="1"> <TR BGCOLOR="yellow"> <TH>nome_processo</TH><TH>autor</TH><TH>versao</TH></TR> <xsl:for-each select="ListadeProcessos/item"> <TR><TD> <xsl:value-of select="nome_processo" /> </TD><TD> <xsl:value-of select="autor" /> </TD><TD> <xsl:value-of select="versao" /> </TD></TR> </xsl:for-each> </TABLE> </BODY> </HTML>
Com a execução do documento XML, no browser Internet Explorer 5, pode-se ver o código acima no formato (apresentação) que segue:
43
RESUMO
Neste capítulo definiu-se processo como sendo um conjunto de atividades inter-
relacionadas que transformam entradas em saídas, e reutilização de processo como
sendo o uso de um modelo de processo, na criação de outro processo. Um modelo de
processo é uma descrição de um processo expresso em uma linguagem de modelagem de
processos.
Apresentou-se o conceito de framework, dentre vários, como sendo o esqueleto de uma
aplicação que pode ser customizada por um desenvolvedor da aplicação [em 47].
Descreveu-se que os frameworks possuem uma parte variável, que são seus pontos de
flexibilização (hot-spots) e possui pontos comuns ao domínio. Para obter-se um
framework, segue-se um processo de desenvolvimento, entretanto isto é uma atividade
árdua e podem ser necessárias várias iterações. Apresentaram-se os tipos de frameworks,
sendo caixas-brancas os que dependem da implementação de um desenvolvedor e os
caixas-pretas que possuem componentes pré-fabricados para serem utilizados.
Destacou-se o conceito de design patterns – como sendo soluções para problemas
recorrentes – e observou-se que embora existam dúvidas, existem alguns pontos que
44
mostram as diferenças entre patterns e frameworks. Por exemplo, patterns são mais
abstratos, são elementos arquiteturais menores, e são menos especializados que
framewoks.
Para auxiliar na reutilização de processos se utilizará o conceito de facetas que são
consideradas como perspectivas, pontos de vistas ou dimensões de um domínio
particular. Definiu-se, para este trabalho, o uso das facetas ação (função) e objeto, que
irão compor os nomes das atividades dos processos.
Finalmente, apresentou-se o XML (Extensible Markup Language – Linguagem de
Marcação Extensível) e XSL (eXtensible Stylesheet Language – linguagem de folha de
estilo extensível). O XML especifica uma meta-linguagem de marcação que permite
representar estruturalmente diversas informações, que podem ser processadas de forma
uniforme. O XML define o conteúdo e estrutura de um documento. O XML fornece um
mecanismo, a DTD – Definição do Tipo de Documento – que define uma gramática ou
conjunto de regras para uma classe de documentos e será utilizada para definir a
linguagem de modelagem de processos. O XSL define a apresentação de um documento e
pode ser utilizada para apresentar processos na web.
45
Capítulo 3 – A Arquitetura para Reutilização de Processos
Este capítulo apresenta a arquitetura proposta para a reutilização de processos e seus
elementos – as linguagens de modelagem de processos, os tipos de processos (standard,
pattern, usual), os frameworks de processo, as instâncias de processo e os guias de reutilização.
Inicialmente, apresenta-se uma visão geral da arquitetura e, posteriormente, cada elemento é
detalhado.
VISÃO GERAL
A arquitetura, no seu estrito senso, é a arte de edificar. Dessa forma, a arquitetura de
processos proposta é a uma organização de processos e elementos correlatos e seus
relacionamentos. O objetivo da arquitetura é organizar processos para viabilizar sua
reutilização. Procura-se, através do uso em conjunto, da organização e estruturação das
informações, facilitar o acesso e reaproveitamento efetivo dos processos. O fato de estar
reutilizando processos tem todos os benefícios conhecidos da tecnologia de reutilização,
sendo possível fazer uso do conhecimento e da experiência adquiridos em processos de
projetos da empresa ou estabelecidos por outras organizações ou pesquisadores [59], [42]
e [43].
A Figura 9 ilustra a arquitetura proposta. A arquitetura possui como elementos a
linguagem de modelagem de processos, os tipos de processos, os frameworks de
processos, os guias de reutilização e as instâncias de processos.
As linguagens de modelagem de processos são notações formais usadas para expressar
modelos de processos, para os tipos de processos e para os frameworks. Os tipos de
processos são os process patterns, process standards e usual process. Process patterns se
referem a soluções para problemas recorrentes relacionados com processos. Com base
nos process patterns pode-se gerar novos processos que podem ser armazenados como
usual process, que não são nem process patterns nem process standards. O usual process
é um processo que é, por exemplo, definido por uma empresa, está em um livro da
literatura ou será definido por um líder de projeto. Process standards são standards na
forma de processos. Eles servem de base para a definição de processos, conforme
determinados standards de melhoria e garantia de qualidade. Usual processes podem
46
estar em conformidade ou não com um standard. Os tipos de processos estão descritos
segundo uma linguagem de modelagem de processos e ficam armazenados em um banco
de dados.
Um framework de processo é definido como um processo genérico, utilizado para gerar
outros processos, com pontos de flexibilização e com pontos comuns. A geração de
outros processos, a partir do framework, é realizada com base nos guias de reutilização.
Um guia de reutilização tem como objetivo auxiliar na reutilização e na instanciação do
framework. Os frameworks são definidos com base nos tipos de processos da arquitetura
e são descritos na linguagem de modelagem de um usual process.
Um engenheiro de processos é o usuário da arquitetura proposta e o interessado na
reutilização. Ele pode gerar instâncias de processos a partir de um framework ou
pesquisando e reutilizando a partir da base de dados dos diferentes tipos de processos.
Uma instância de processo é um processo do tipo usual process.
INSTÂNCIAS DE PROCESSOS
Pontos Comuns
Pontos de Flexibilização
Kernel
Hot-Spots
FRAMEWORKS DE PROCESSOS
UsualProcess
Process Patterns
ProcessStandard
Framework
Atividade y
Atividade x
GUIAS DE REUTILIZAÇÃO
LINGUAGENS DE MODELAGEM DEPROCESSOS
TIPOS DEPROCESSOS
Figura 9 – Arquitetura para Reutilização de Processos
47
LINGUAGEM DE MODELAGEM DE PROCESSOS
Uma linguagem de modelagem de processo é uma notação formal usada para expressar
modelos de processos. Um modelo de processo é uma descrição de um processo expressa
em uma linguagem de modelagem de processo [65]. Um modelo é sempre uma abstração
da realidade que ele representa, portanto alguns aspectos do processo podem ser que não
sejam capturados. O modelo pode consistir, por exemplo, de formulários ou de tipos para
descrever vários elementos do processo.
Uma variedade de propostas de paradigmas múltiplos (multi-paradigm approach) tem
sido apresentadas para modelar processos de software. Muitas delas estão descritas em
Finkelstein at all [65]. Todas estas propostas estão centradas em um paradigma principal,
como regras, por exemplo, Marvel, Merlin e Oikos [em 65]; programas imperativos, por
exemplo APPL/A e IPSE 2.5 [em 65 ] ou; Petri Nets, como por exemplo Slang [em 65].
Uma característica básica de todas elas, com exceção da proposta PetriNets, é que todas
usam representação textual.
Para formalizar a linguagem e expressar o modelo de processos escolheu-se o XML.
Como definido, o XML especifica uma meta-linguagem de marcação que permite
representar estruturalmente diversas informações que podem ser enviadas/ recebidas e
processadas na WEB de forma uniforme. Como os processos, por natureza, possuem uma
estrutura hierárquica adotou-se o XML, tomando proveito de seus benefícios, para
trabalhar com a estruturação de documentos. Cada modelo de processo é descrito em um
documento XML. Como também apresentado, a DTD – Definição do Tipo de
Documento – contém ou aponta para marcações declarativas que definem uma gramática
ou conjunto de regras para uma classe de documentos. Cada tipo de processo representa
uma classe de documento. Sendo assim, definiram-se DTDs criando-se linguagens para
modelar os diferentes tipos de processos. Criaram-se três DTDs, uma para usual process,
uma para process pattern e uma para process standard.
É importante enfatizar que cada um dos tipos de processos tem uma finalidade e,
portanto, esses tipos podem conter diferentes elementos em sua descrição, embora muitos
deles sejam comuns. Todos os tipos de processos têm uma parte com elementos comuns
48
na sua linguagem, permitindo que a instância gerada possa armazenar estes elementos
comuns provenientes de qualquer um dos diferentes tipos de processos. A linguagem para
os process patterns é uma evolução [66] dos formulários (templates) oriundos de estudos
dos design patterns (Alexander [67], GOF [33] e Coplien [36]). Para os outros tipos de
processos, a base foi pesquisas anteriormente realizadas [66] [42] [53] [68] incluindo-se
os conceitos de frameworks [33] [47].
A base da meta-linguagem XML são declarações de elementos e atributos. A seguir,
exemplifica-se uma parte da linguagem para um usual process definida na XML.
?xml version="1.0" encoding="UTF-8"?>
<!-- edited with XML Spy v3.0 (http://www.xmlspy.com) by Soeli Fiorini -->
<!--DTD generated by XML Spy v3.0 (http://www.xmlspy.com)-->
<!-- A seguir define-se o elemento atividade macro que possui vários filhos – sub-elementos, que também devem ser
definidos -->
<!ELEMENT PrcAtividadeMacro (AtvNome, AtvDescricao, AtvPreCondicao?, AtvEntrada, AtvSaida, AtvPredecessor?,
AtvPosCondicao?, AtvRestricao?, AtvRspNome, AtvMetodoTecnica?, AtvFerramenta?, AtvAtividadeDetalhada*)>
<!-- Agora deve ser definido cada sub-elemento da atividade macro, até que o sub-elemento não tenha mais filhos,
quando então deve-se dizer o tipo do elemento -->
<!ELEMENT AtvNome (AtvAcao, AtvSinonimo, AtvObjeto)>
<!ELEMENT AtvAcao (#PCDATA)>
<!ELEMENT AtvSinonimo (#PCDATA)>
<!ELEMENT AtvObjeto (#PCDATA)>
<!ELEMENT AtvDescricao (#PCDATA)>
No exemplo acima, definiu-se o elemento atividade macro e seus “filhos” (sub-
elementos). A ordem em que os “filhos” aparecem dentro do elemento é a ordem em que
as informações deverão aparecer no documento. Os símbolos “?” e “*” indicam,
respectivamente, que o elemento é opcional e que o elemento pode ocorrer 0 ou n vezes
no documento.
No próximo Capítulo, a linguagem de modelagem de processos, para cada tipo de
processo e frameworks, é descrita em detalhes.
TIPOS DE PROCESSOS
Geralmente, quando se define um processo, inicia-se uma busca por um processo
existente na organização ou em outras organizações, ou um que exista na literatura.
49
Também se recorrem aos consultores em processos, detentores do conhecimento em
modelagem. Muitas vezes, também, é necessário que o processo esteja em conformidade
com algum modelo ou norma. Quando não se tem nenhum processo, estes modelos ou
normas se tornam guias de referência para a definição dos processos. Baseado nestas
observações definiu-se os seguintes tipos de processos: process standard (processo
standard), process pattern (pattern de processo) e usual process (processo usual). Adota-
se o nome em inglês, visto que as palavras standard e pattern têm sentidos diferentes na
língua inglesa, mas não na portuguesa – elas têm a mesma tradução (padrão). Isto poderia
tornar confusa a definição desenvolvida nesta tese. Nos próximos itens, descreve-se cada
um dos tipos de processos.
3.1.1 PROCESS STANDARD
Existem vários modelos e normas5, para melhoria e definição de processos e garantia de
qualidade, que neste trabalho denomina-se standards. Entre as normas, por exemplo, está
a ISO/IEC 9000-3 [69] para garantia da qualidade de software e a família ISO/IEC
9000:2000 [95]6, como um todo, e a ISO/IEC 12207 [51] para estabelecimento de
estrutura comum de processos de ciclo de vida de software. Dentre os modelos de
melhoria de processos destacam-se Trilhum [19], Bootstrap [20] e CMM [39]. Todos eles
são utilizados como base para a definição e melhoria dos processos.
Geralmente, a pessoa responsável em definir um processo em conformidade com um
standard lê o conteúdo deste e “mapeia” as regulamentações dentro de um modelo de
processo. No entanto, os standards precisam de interpretação para ser aplicados e muitos
deles são muito genéricos, não definindo alguns detalhes de suas atividades de forma
explícita. Dessa forma, nesta tese organiza-se a descrição dos standards, de tal forma que
5 Está fora do escopo desta tese a análise de standards voltados para a qualidade de produto e modelos
como o SPICE (modelo de avaliação).
6 A revisão da ISO 9000:2000 tem como grande modificação a substituição do objetivo de garantia de
qualidade (atendimento aos requisitos especificados) para o de satisfação do cliente, onde esta satisfação
está relacionada principalmente com a percepção da qualidade dos produtos e serviços fornecidos o que
envolve não só os requisitios especificados, ou seja explícitos, mas também os requisitos implícitos [96].
50
apresente os elementos mínimos de um processo (pré-condição, entrada, nome atividade,
descrição, saídas, pós-condição), deixando mais evidente as atividades a serem
realizadas. A este standard na forma de processo, denominamos process standard. Sendo
assim, define-se:
Process standard é um standard na forma de processo. Ele serve de base para a
definição de processos, conforme determinados standards de melhoria e garantia de
qualidade. Ele tem a finalidade normativa.
A seguir, apresenta-se um exemplo de um item (ou atividade). O item é “revisar
requisitos de sistema”, do CMM – área-chave gerência de requisitos. O exemplo é parte
de um documento XML (mostra o processo – estrutura e conteúdo – descrito segundo a
linguagem do process standard):
EXEMPLO
.....
<!--ITEM REVISAR REQUISITOS -->
<SubScItem>
<ItmNome>
<NmAcao>Revisar</NmAcao>
<NmSinonimo>rever</NmSinonimo>
<NmObjeto>requisitos alocados</NmObjeto>
</ItmNome>
<ItmReferencia>Atividade 1 de Gerência de Requisitos</ItmReferencia>
<ItmPre_Condicao>Ter as responsabilidades estabelecidas para analisar e alocar
os requisitos (habilitação 1)</ItmPre_Condicao>
<ItmEntrada Entrada="PoliticaOrgRequisitos Recursos_e_Fundos
TreinamentoGerRequ RequisitosDocumentados"/>
<ItmDescricao>Identificar, por exemplo, se algum requisito está ausente, se os
requisitos podem ser implementados, se estão bem declarados, consistentes uns
com os outros, se são testáveis e implementáveis. Documentar as alterações
necessárias e negociar os compromissos resultantes com os grupos envolvidos e os
gerentes de software.</ItmDescricao>
<ItmRestricao>A atividade deve ser realizada antes de incorporar os requisitos
ao projeto de software</ItmRestricao>
<ItmSaida Saida="RequisitosRevistos"/>
51
<ItmPos_Condicao>Usar os requisitos como base para o desenvolvimento do
software (planos, artefatos e atividades) - Atividade 2</ItmPos_Condicao>
<ItmResponsavel>grupo de engenharia de software</ItmResponsavel>
</SubScItem>
Um esforço neste sentido, modelar standards na forma de processo, é o GDPA
(Graphical Design Process Assistant) – um standard para um meta processo [70]. Nele,
foram analisados seis standards. Na análise, observou-se que, embora standards
organizem e classifiquem atividades em diferentes maneiras, quase todos eles podem ser
modelados em três níveis. A tabela a seguir ilustra a análise de dois standards com seus
referidos níveis (denotam a organização estrutural do standard) e um exemplo de
conteúdo de cada nível:
Standard ISO/IEC 12207
Exemplo do conteúdo CMM Exemplo do conteúdo
1º Nível Ciclo de Vida Processo fundamental do ciclo de vida
Nível Nível 2
2º Nível Processo Processo de aquisição Área-chave (KPA)
Gerência de requisitos
3º Nível Atividade Inicializar Atividade Revisar requisitos alocados
Tabela 1 – Exemplo de standards e seus referidos níveis (adaptada de GDPA [70])
Maiores detalhes sobre a linguagem de modelagem dos standards são fornecidos no
próximo Capítulo.
3.1.2 PROCESS PATTERNS
Patterns, como apresentado no capítulo conceitos básicos, têm o objetivo de apresentar
soluções para problemas recorrentes, que acontecem num determinado contexto. De
acordo com sua definição, eles não podem ser novos ou hipotéticos [33] [56].
Existem algumas definições relacionadas a process patterns, algumas são genéricas e
outras são mais específicas. Citam-se algumas a seguir:
a) Coplien [25] [58] foi um dos primeiros a contribuir na área de process pattern e
organizational patterns. Ele propôs uma linguagem de patterns para descrever e construir
52
novas organizações. Ele considera, preferivelmente, patterns genéricos que cobrem
aspectos sociais e organizacionais do processo de desenvolvimento de software. Os
patterns auxiliam na construção de novas organizações, além de ajudar a entendê-las,
sendo que os patterns podem auxiliar, indiretamente, a definir processos corretos.
Entretanto, não distingue process pattern de organizational pattern.
Segundo definição encontrada em [72], do projeto Catalysis (proposta orientada ao
desenvolvimento de componentes e design reutilizável):
Process Patterns são utilizados no processo de software ou sistema de desenvolvimento e
manutenção. A idéia é capturar a sabedoria das táticas e estratégias de software, em
pequenas partes tratáveis.
A forma é:
Sempre que a meta for xxx
e sua situação corrente for yyy
então tente fazer zzz
(mas esteja atento para os pré-requisitos ppp, riscos rrr, efeitos colaterais sss, ....)
b) Scott Ambler – um dos únicos autores com livros específicos para process patterns –
Process Patterns [21] e More Process Patterns – descreve um processo de software,
segundo ele maduro, para o paradigma de orientação a objetos, definido com base na sua
experiência e nas práticas do CMM. Segundo ele:
Process Patterns descrevem uma coleção de técnicas, ações e/ou tarefas (atividades)
gerais para desenvolver software orientado a objetos. De muitas formas, process
patterns são blocos de construção reutilizáveis a partir dos quais sua organização pode
adaptar um processo de software maduro.
53
Entretanto, de acordo com Ambler, para serem satisfatórios, não é suficiente ter apenas
uma coleção de process patterns, é preciso ter uma linguagem para os manterem juntos,
como um todo consistente, formando um processo de software completo.
c) Vasconcelos e Werner [24] definem process patterns como patterns que lidam com o
conhecimento de processos. Para os autores, estes patterns tratam questões como equipes
organizacionais [25], organização das atividades de desenvolvimento [24] e análise de
requisitos [26].
No âmbito deste trabalho, define-se:
Process Pattern: é um pattern que provê soluções estruturadas para problemas
relacionados aos processos.
Por exemplo, tratando-se de Engenharia de Software, teriam-se process patterns para o
processo de desenvolvimento de software ou mais especificamente para o processo de
engenharia de requisitos. Por exemplo, relacionado com a atividade de negociação
(comunicação) com o cliente no processo de requisitos, “como definir e estabelecer um
relacionamento bom e contínuo com o Cliente durante o desenvolvimento de software?”.
Os process patterns podem definir soluções para processos em diferentes níveis de
granularidade.
Na definição de um process pattern as mesmas “regras” usuais de criação de um pattern,
como por exemplo, não pode ser hipotético, deve solucionar um problema e a solução
não pode ser óbvia [56], devem ser aplicadas.
3.1.3 USUAL PROCESS
É qualquer processo existente que nem é um process standard nem é um process pattern.
Refere-se a grande maioria dos processos. Ele não é um process standard porque não tem
a finalidade normativa. Não é um process pattern porque ele não necessariamente precisa
54
ter sido testado (aplicado), em um considerável número de vezes, para solucionar um
problema recorrente.
INSTÂNCIAS DE PROCESSO
Uma instância de processo é um processo do tipo usual, gerado a partir de um framework
ou de outro processo qualquer (pattern, usual ou standard) ou da combinação destes.
Pode-se exemplicar a geração de uma instância, imaginando-se um usual process que
fosse utilizado por vários projetos (padrão para a organização [40]), mas como os
projetos têm características diferentes, cada projeto geraria uma instância reutilizando o
que é comum do usual process, acrescentando novas atividades quando necessário. Para
definir uma instância de processo, inicialmente cria-se um usual process.
A Figura 10 mostra as operações básicas que podem ser realizadas para se gerar a
instância de processo. Em todas as bases o engenheiro de processos pode pesquisar e
reutilizar parcialmente os elementos (por exemplo, atividades, treinamentos, métodos/
técnicas, entradas e saídas). A reutilização total, reutilizar todo o processo, só aplicável
para usual process, pois é a mesma linguagem da instância. Incluir, editar e excluir
referem-se as operações para, respectivamente, criar a instância e adaptar a instância. A
operação criar um usual process baseado no process pattern, é usada quando o
engenheiro de processos achou o process pattern aplicável à sua situação, mas no
entanto, prefere defini-lo à sua maneira. Depois de realizadas algumas das operações
descritas, o engenheiro de processos pode gravar a instância de processo. Ela será
armazenada como um usual process. Maiores detalhes sobre as operações para gerar uma
instância de processos são descritos no Capítulo 6.
55
INSTÂNCIAS DE PROCESSOS
TIPOS DE PROCESSOS
USUAL PROCESS
PROCESS PATTERNS
ENGENHEIRODE PROCESSOS
EXCLUIREDITAR
PESQUISARREUTILIZAR PARCIAL/
TOTALREUTILIZAR FRAMEWORK
OPERACÕES:
PESQUISARREUTILIZAR PARCIAL
CRIAR USUAL PROCESSBASEADO NO
PROCESS PATTERNENGENHEIRO
DE PROCESSOS
PROCESSSTANDARD
ENGENHEIRODE PROCESSOS
PESQUISARREUTILIZAR PARCIAL
GRAVAR
INCLUIR
Figura 10 – Operações realizadas para gerar instâncias de processos.
FRAMEWORK DE PROCESSO
Frameworks de aplicação são abstrações de um conjunto de aplicações de um
determinado domínio [47]. Geralmente são aplicações incompletas que serão finalizadas
durante a sua instanciação.
Para os objetivos deste trabalho um framework de processo é definido como um processo
genérico utilizado para gerar outros processos. Ele é uma generalização de um
determinado conjunto de processos de um determinado domínio. Ele possui uma parte
fixa e uma parte variável. A parte fixa é composta de atividades comuns a maioria dos
processos que podem ser instanciadas pelo framework. A parte variável (hot-spots) é
composta de atividades e elementos do processo que definem características ou caminhos
específicos de uma instância do framework. Os hot-spots são preenchidos pelo
engenheiro de processos, selecionando componentes existentes ou redefinindo/ definindo
a descrição dos elementos do processo. Como mencionado o framework é descrito como
um usual process. O Capítulo 5 disserta sobre o desenvolvimento de framework de
processos.
56
Os atores envolvidos na definição do framework de processos são o engenheiro de
domínio, quem faz a análise do domínio dos processos, e o engenheiro de processos,
quem cria o framework. O engenheiro de processos por vezes pode desempenhar os dois
papéis. A instanciação do framework, quando se gera a instância de processo, é realizada
por outros engenheiros de processos ou, por exemplo, pelo gerente do SEPG – Software
Engineering Process Group (Grupo de Processos de Engenharia de Software). Visto a
necessidade de fornecer um apoio ao engenheiro de processos, a fim dele definir seu o
processo (instância) e obter o maior proveito do framework e dos dados existentes nas
bases de dados, definiram-se os guias de reutilização. Os dados existentes nas bases de
dados de usual process, para estudos desta tese, foram provenientes da análise de sete
processos de engenharia de requisitos, provenientes da literatura [82], [83], [84], [85],
[86] [87] e [88] e um proveniente de uma empresa [54] certificada CMM N2. O
framework disponível foi também baseado na análise dos sete processos da literatura
citadados. Os process patterns foram oriundos da literatura (RAPPeL [26]), assim como
os process standards (CMM [17] e ISO 12207[51]). Com base no processo de
desenvolvimento descrito (Capítulo 5), o engenheiro de domínio/ engenheiro de
processos podem definir frameworks de processos para povoarem a base de dados. A
base de dados também conterá usual process e process patterns por eles definidos ou
capturados do mercado ou literatura. A seguir, os guias de reutilização são descritos e
ilustrados.
GUIAS DE REUTILIZAÇÃO
Um guia de reutilização (Figura 11) tem como objetivo auxiliar na reutilização e na
instanciação do framework. Existem dois tipos de guias, o guia do framework e os guias
de cada atividade macro. O guia do framework, como um todo, provê uma visão das
atividades macro e oferece suporte à instanciação destas atividades. O guia de cada
atividade macro fornece uma visão das respectivas atividades detalhadas. No topo do guia
(Figura 11), encontra-se o nome do framework ou da atividade macro e, no caso desta
última, indica-se se ela é um ponto comum ou um ponto de flexibilização no framework.
57
No guia de atividade são identificadas, as características, os componentes, os process
patterns e os process standards associados.
As atividades estão no guia como referência, pois estão descritas no usual process. As
características fornecerão suporte ao engenheiro de processos para decidir sobre manter
ou não atividades, como por exemplo as [OP]cionais, na instância a ser gerada. Os
componentes auxiliarão mostrando “atividades prontas” que podem ajudar na
complementação de atividades comuns ou no preenchimento/ redefinição de pontos de
flexibilização. Os process standards e patterns associados às atividades têm este mesmo
objetivo.
O desenho do guia (Figura 11) segue uma estrutura baseada em hot-spot card [34],
modelo de características [71] e conceitos de reutilização de componentes – 3C [72]. A
seguir detalha-se cada um deles:
Nome Processo ou Atividade
Conceito ( ) Framework
( ) Atividade
( ) Pto. Comum - kernel
( ) Pto. Flexibilização - hotspot
-
Conteúdo
Atividades Características Componentes
EOP, RE, PA
Nome ativ. 1Nome ativ. n
Comp. xComp. y
Contexto
P.Standard/Pattern
Situações do contexto ...... Usar ...
Figura 11 – Guia de reutilização
O modelo 3Cs: de design de reutilização (model of reuse design) provê uma estrutura
que tem sido efetiva no design de ativos reutilizáveis [72]. Esse modelo indica três
aspectos de um componente reutilizável – seu conceito, seu conteúdo, e seu contexto. O
conceito indica a semântica abstrata do componente, o conteúdo especifica sua
58
implementação, e o contexto especifica o ambiente necessário para usar o componente.
Na Tabela 1 encontra-se um exemplo da documentação dos componentes, para
reutilização código, no modelo 3Cs. Na tabela 2 encontra-se o mesmo Modelo aplicado
para processo.
MODELO 3Cs CÓDIGO
Conceito Tipo Abstrato de Dado (ADT) Conteúdo “Implementado em C” Contexto “Sistema operacional = UNIX, Hardware = Sun, Compilador =
ANSI C”
Tabela 2- Exemplo do Modelo 3Cs para Código [29]
MODELO 3Cs ELICITAR REQUISITOS
Conceito Atividade macro – ponto comum Conteúdo O objetivo de elicitar requisitos é ....
Atividades: Coletar Fatos ..... .....
Características: [CO]mum, [E]ssencial
Componentes: Adquirir conhecimento ......
P.Standards Analisar requisitos (CMM)
P. Patterns -
Contexto Na situação onde deseja-se ... use a técnica y É preciso reduzir a falta de consenso Brainstorming - BDCA
Tabela 3 – Exemplo do Modelo 3Cs aplicado para processos
Na seção “Conceito” do guia de reutilização, encontram-se informações se o guia
apresentado é do framework ou se é de uma atividade macro. Identifica-se, também, para
o caso das atividades, se elas são um ponto de flexibilização ou não.
Na seção “Conteúdo”, são identificadas, para cada atividade do framework, as suas
características, os componentes aplicáveis, process standard e process patterns. Para
cada um deles é possível realizar uma consulta aos seus dados. Tanto os componentes,
atividades de outros usual processs, quanto os process patterns e process standards do
guia, possuem ligações com as bases de dados definidas e podem ser reutilizados, por
exemplo para preencher hot spots. Desta forma, as interfaces (entradas e saídas) de cada
uma delas podem ser consultadas. Os itens de process standards associados, que são
equivalentes às atividades/ práticas de um modelo ou norma, também complementam
59
descrições ou preenchem atividades do framework. Por exemplo, uma prática do process
standard CMM “Revisar requisitos ..”, poderia estar associada com uma atividade “fazer
revisões” do framework. Os process patterns associados às atividades são soluções para
problemas recorrentes relacionados com processos, e auxiliam na complementação ou
definição de descrições de uma atividade, ou podem ser a própria atividade.
Na seção “Contexto”, no guia do framework, aponta-se para os guias das atividades
macros onde pode-se encontrar as descrições de “situações do contexto”. Uma situação
de contexto refere-se a um determinado estado ou ambiente no qual o projeto está
inserido ou que os envolvidos estão passando. Esta situação, muitas vezes, dita
necessidades. Neste trabalho as situações ditam o uso de determinados métodos/ técnicas.
Portanto, nas atividades macro os métodos/ técnicas são pontos de flexibilização que
associados ao contexto podem ser utilizados ou não. Em frameworks onde situações do
contexto são melhor conhecidas e os caminhos alternativos dentro do processo estão
definidos pode-se então descrever o uso de determinadas atividades ou não e a variação
de sua descrição. No guia do framework, no contexto, também tem uma indicação para
consultar o elemento características do processo que também define alguns detalhes do
contexto. O Capítulo 5 apresenta um exemplo de um guia de um framework e um guia de
uma atividade macro.
Modelo de Características: as características (features) têm o objetivo de “capturar a
visão do usuário final, sobre os requisitos das aplicações de um determinado domínio, em
um modelo” –Feature Oriented Domain Analysis [71] (Análise de Domínio Orientada à
Características). Nesse trabalho, utilizam-se as características como um modelo
semântico, similar a [73]. As características são atributos das atividades, que são
definidas durante a análise de domínio, a fim de auxiliar na definição e instanciação do
framework de processo. Elas servem para organizar as atividades do framework,
identificando quais atividades são pontos de flexibilização e quais são pontos comuns. As
características possuem informações sobre a frequência com que as atividades aparecem
no domínio, “servindo de base” para a tomada de decisões na hora da instanciação. Por
60
exemplo, uma atividade com característica comum (alta frequência) será reutilizada.
Entretanto, a atividade com maior frequência não necessariamente é a mais importante,
embora isto seja, na maior parte das vezes, coerente na análise de domínio de processos.
Conforme descrito anteriormente, a identificação das características ocorre durante a
análise de domínio dos processos, e irão auxiliar na elaboração dos guias de reutilização.
O engenheiro do domínio captura, através da análise de processos, determinadas
características relevantes, a fim de que o engenheiro de processos, no momento da
reutilização, tenha uma referência sobre as atividades do processo naquele domínio. Para
definir as características ele seleciona alguns processos do domínio (por exemplo, três
processos do domínio de engenharia de requisitos), escolhe um processo base, seleciona
uma atividade deste processo e a compara com as atividades dos outros processos (outros
dois processos selecionados). Dessa forma, ele verifica se a atividade se repete nos outros
processos. Cada vez que a atividade se repete contabiliza-se um ponto. De acordo com a
pontuação são estabelecidads as características. Repetem-se os mesmos passos quando se
deseja definir as características de outras atividades do processo. No Capítulo 5 está
descrito de forma detalhada como se definem as características dos processos baseado na
comparação das atividades.
As características definidas para as atividades são:
[CO]mum: a característica indica que a atividade é comum, no conjunto de processos
analisados no domínio, quando a atividade aparecer em mais de 75% dos processos
analisados7. Não se usa a frequência = 100%, como comumente subentende-se nos
processos de análise de domínio, pois restringiria muito a identificação dos pontos
comuns. Processos estão em um nível alto de abstração e, processos de engenharia de
software, que é o objetivo alvo, ainda não são totalmente maduros, bem definidos, o que
dificulta realizar esta tarefa de análise e identificação do que é comum. Isto difere dos
frameworks de aplicação que são menos abstratos.
7 No Capítulo 5, define-se como é medida a frequência com que a atividade se repete no domínio. Com
base em um processo de análise realizado definiu-se por “amostragem” os percentuais.
61
[OP]cional: a característica indica que as atividades não são mandatórias no domínio.
Elas são pouco comuns nos processos analisados.
[E]ssencial: quando a atividade tem muita importância dentro do domínio, ou seja ela é
fundamental. São “ligadas a essência do domínio”[73]. A importância da atividade é
medida pela frequência (>75%) com que ela se repete nos processos analisados do
domínio. Atividades com características [E]ssenciais são pontos [CO]muns no domínio.
[REC]omendável: quando a atividade não tem uma frequência muito alta, mas ainda
causa influência no domínio. Sendo assim, no momento da reutilização, ela deverá ter
uma atenção especial e, se o contexto permitir, recomenda-se que seja reutilizada. Ela
tem uma frequência entre 74% e 50% .
[AN]alisada: quando a atividade tem uma frequência entre 49% a 25% ela deve ser
analisada de forma a verificar se atividade pode contribuir para o processo que está sendo
definido.
[ES]pecífica: quando a atividade é específica de poucos processos do domínio. Elas
representam particularidades de determinados processos.
Para as atividades no nível detalhado (tarefas), utilizaram-se as seguintes características:
[IM]plícita: a característica indica que a atividade em questão, embora não apareça
explicitamente como uma atividade nos outros processos analisados, encontra-se
implícita nas descrições daqueles processos. Por exemplo, a atividade “Coletar Fatos”
muitas vezes está implícita em textos como “consultar stakeholders” ou “elicitar
informações de usuários finais, clientes, ..”. Se uma atividade possuir a característica
[IM]plícita e for [OP]cional o engenheiro de processos deverá analisar se ela não é
importante para o contexto em questão.
[FO]ra: a característica indica que a atividade detalhada tem uma ou mais referências
fora da sua atividade-macro, ou seja, a atividade em questão encontra uma outra igual/ou
similar em outra atividade-macro, ou é uma outra atividade-macro. Por exemplo,
“Comunicar Cliente” foi definida por um autor como atividade detalhada da atividade-
macro “Elicitar Requisitos”. No entanto, “Comunicar Cliente” aparece como uma
62
atividade macro em outro processo, de outro autor, como sendo “Negociar com Cliente”.
Com esta característica, o engenheiro de processos, terá que decidir se ela fica no nível
macro ou detalhado, e em que atividade macro, caso ele reutilize essa atividade.
Hot-spots Card: Segundo Pree [34], um hot-spot card deve fornecer o nome do ponto de
flexibilização (hot-spot); fornecer um termo conciso descrevendo a funcionalidade
(correspondendo aos métodos ou responsabilidades) que deverá ser mantida flexível; e
especificar o grau de flexibilidade. Neste trabalho, os hot-spot cards não são utilizados
como tal, apenas serviram como a “idéia” inicial para montar os guia de reutilização.
Comparando-os, os hot-spot cards são aplicáveis apenas para os pontos de flexibilização,
e o guia de reutilização, por ser mais genérico, é aplicado para o framework como um
todo, tanto para seus pontos de flexibilização quanto para os seus pontos comuns. Quanto
as informações presentes em cada um deles, fazendo um paralelo entre o hot-spot card e
o guia de reutilização, temos respectivamente:
§ o nome do ponto de flexibilização (hot-spot) – visualiza-se no cabeçalho do guia de
reutilização o nome do processo ou atividade. Entretanto as informações da
flexibilização (ponto comum ou de flexibilização) encontram-se na seção “Conceito”
do guia.
§ um termo conciso descrevendo a funcionalidade – no guia, na seção “Conteúdo”, é
apresentado a atividade e a sua descrição. O nome dos componentes da atividade
conduzem, através de links, para outras descrições similares.
§ especificação do grau de flexibilidade: no guia, a seção “Conceito” define as
características e no “Contexto” definem-se quando os métodos/ técnicas podem ser
utilizados. Cada atividade do processo que está no guia possui alguns métodos e
técnicas. Estes métodos e técnicas são uma coletânea dos métodos e técnicas da
atividade que se encontrava nos diferentes processos analisados durante a análise de
domínio, que foi realizada para definir as características das atividades.
63
RESUMO
Este capítulo apresentou a arquitetura para reutilização de processos e seus elementos –
as linguagens de modelagem de processos (uma introdução), os tipos de processos
(standard, pattern, usual), os frameworks de processo, as instâncias de processo e os
guias de reutilização.
A linguagem de modelagem de processos é uma notação formal usada para expressar
modelos de processos. Como os processos, por natureza, possuem uma estrutura
hierárquica, adotou-se o XML para definir as linguagens de modelagem de processos. O
XML é uma meta-linguagem definida para trabalhar, de forma simples, com a
estruturação de documentos. Os tipos de processos são vistos como documentos XML e a
sua especificação encontra-se em uma DTD – Definição do Tipo de Documento. A DTD
contém ou aponta para marcações declarativas que definem uma gramática ou conjunto
de regras para uma classe de documentos. Dessa forma, foi definida uma DTD para o
process standard, uma para o process pattern e uma para o usual process.
Um process pattern é um pattern que provê soluções estruturadas para problemas
relacionados aos processos. Os process patterns podem ser base para gerar novos
processos que podem ser armazenados como usual process, que não são nem process
patterns nem process standards. Process standards são standards na forma de processos.
Eles servem de base para a definição de processos, conforme determinados standards de
melhoria e garantia de qualidade. Usual processes podem estar em conformidade ou não
com um standard. Os tipos de processos estão descritos segundo uma linguagem de
modelagem de processos e ficam armazenados em um banco de dados.
O framework de processos é definido como um processo genérico usado para gerar outros
processos. Essa geração, a partir do framework, é realizada com base nos guias de
reutilização. Um guia de reutilização tem como objetivo fornecer suporte à reutilização e
à instanciação do framework.
Um engenheiro de processos, que é o usuário da arquitetura proposta, gera instâncias de
processos a partir do framework ou a partir da pesquisa e da reutilização das base de
dados dos diferentes tipos de processos. Uma instância de processo é um processo do tipo
usual process.
64
Capítulo 4 – A Linguagem de Modelagem de Processos
Este capítulo descreve como foi definida a linguagem de modelagem dos diferentes tipos de
processos, considerando aspectos de reutilização. Descreve-se a especificação dos elementos
da linguagem do usual process, process pattern e process standard. Em anexo (A), introduz-se o
conceito da parte lógica do XML – a meta-linguagem utilizada – e apresenta-se a especificação
completa da linguagem para os diferentes tipos de processos.
MODELOS DE PROCESSOS
A descrição de um processo expressa em uma linguagem de modelagem de processo –
um modelo de processo [74] – é essencial para o sucesso de programas de melhorias de
processos de software (Software Process Improvement – SPI). Primeiro, uma vez que um
processo está documentado, pode-se controlar as suas versões e mudanças, ou seja, pode-
se estabelecer baselines de processos. Segundo, o modelo de processo é necessário para
que se possa definir pontos de medições. Terceiro, modelos de processos permitem que
experiências e aprendizados sejam compartilhados dentro e entre organizações [14] [42]
[43]. Entretanto, segundo Becker et all [75], ainda não existe experiência suficiente com
respeito a como modelar processos descritivamente. Os mesmos autores, após
conduzirem experimentos no contexto industrial em programas de melhoria, relatam,
entre outros, que:
- os modelos de processos, embora sejam formulados de uma forma rigorosa, não
deveriam ser utilizados rigorosamente (processos de desenvolvimento de software
são estocásticos (stochastic) e não determinísticos e desenvolvedores precisam de
liberdade para interpretações pessoais);
- o comportamento estocástico e a permanente mudança de processos não permite,
utilizando-se as técnicas correntes, ter uma descrição precisa de todas as variantes de
um processo;
65
- Muitas das linguagens de modelagem de processo correntes dão ênfase em modelos
de processos precisos para a finalidade de automação. Mais pesquisa é necessária no
desenvolvimento de uma estrutura conceitual genérica para modelagem de processos.
4.1.1 PESQUISAS ANTERIORES COM PROCESSOS DE SOFTWARE
Este trabalho sobre processos tem suas origens em trabalhos de pesquisa anteriores [52]
[53] onde foi realizada a descrição de processos de negócio, informal, com o intuito de
elicitar daqueles processos, através de heurísticas, requisitos de sistema de software.
Posteriormente, em trabalhos práticos voltados para a definição e melhoria de processos
[54], buscando-se a certificação de uma organização no modelo CMM, desenvolveu-se
um padrão para documentação de processos, baseado em [76]. Com o referido padrão
foram mapeados 15 áreas-chave de processos do nível 2 e 3 do CMM (229 práticas).
Equipes, de aproximadamente 5 pessoas, denominadas de PATs – Process Action Teams
(Equipes de Ação de Processos) formada por gerentes, analistas e desenvolvedores eram
os responsáveis pela definição dos processos (cada área-chave do CMM). Entetanto, as
equipes não tinham experiência na definição de processos e gastaram por vários meses
cerca de 12% de seu tempo (considerando 40 horas semanais) sendo que, ao final, quase
todas as equipes chegavam com descrições de processos incompletas tendo de serem
finalizadas pelo engenheiro de processos. Os principais problemas não estavam centrados
na linguagem de definição de processos, mas sim na dificuldade de interpretar o modelo
CMM e encontrar descrições de processos similares nas quais os PATs pudessem se
basear para definir os processos para a sua organização. Muito tempo foi despendido em
estudos e pesquisas relacionados a cada tópico de cada área-chave, na formulação de
templates e nas medições. Mais tempo ainda foi gasto com a documentação dos
processos. Embora existisse um padrão, toda a documentação era definida no MS-Word e
a disponibilização em “manuais” dificultava o controle das constantes mudanças,
principalmente no início da institucionalização dos processos.
Esta experiência demonstrou a necessidade de se ter dados de processos organizados de
tal forma que propiciem a sua reutilização. Também comprovou a dificuldade das
pessoas, não especialistas, em registrarem o conhecimento de processos.
66
4.1.2 ORGANIZAÇÃO E DESCRIÇÃO DE PROCESSOS VOLTADA PARA A
REUTILIZAÇÃO
Os aspectos centrais na organização de processos com vistas a reutilização são
classificação e recuperação. Aspectos de “colaboração”, ou seja, como cada tipo de
processo pode colaborar com informações para a construção de uma instância de um
processo, também foram uma preocupação. Para que a linguagem de processos não
ficasse rígida, optou-se por ter elementos do processo opcionais, podendo-se escolher em
preenchê-los ou não. Isto se justifica pela necessidade de descrever diferentes processos
em diferentes graus de complexidade e porque muitos processos de software ainda são
imaturos.
Na classificação e busca de dados dos processos, além das facetas e da própria
estruturação de cada um dos tipos de processos, que será apresentada neste capítulo,
foram definidos alguns outros elementos:
• Para usual processes
a) Elemento classificação do processo – define a classificação segundo a norma ISO/IEC
12207 (Tecnologia de informação – Processos de ciclo de vida de software) [51] – ou
seja:
ü processos fundamentais do ciclo de vida: aqueles processos que atendem as partes
principais (pessoa ou organização – que inicia ou executa o desenvolvimento,
operação ou manutenção dos produtos de software) durante o ciclo de vida de
software. Os processos fundamentais são os de aquisição, fornecimento,
desenvolvimento, operação e manutenção;
ü processos de apoio de ciclo de vida: um processo de apoio provê suporte a um outro
processo como uma parte integrante, com um propósito distinto, e contribui para o
sucesso e qualidade do projeto de software. Os processos de apoio são os de
documentação, gerência de configuração, garantia de qualidade, verificação,
validação, revisão conjunta, auditoria, e resolução de problema;
ü processos organizacionais de ciclo de vida: são empregados por uma organização
para estabelecer e implementar uma estrutura subjacente, constituída de processos
67
de ciclo de vida e pessoal associados, e melhorar continuamente a estrutura e os
processos. São tipicamente empregados fora do domínio de projetos e contratos
específicos. Os processos organizacionais são os de gerência, infra-estrutura,
melhoria e treinamento.
b) Elemento característica do processo – define atributos do usual process que o
caracterizam e limitam o seu uso. Estes atributos irão auxiliar o engenheiro de processos
na busca dos dados desejados, de acordo com o seu contexto.
ü área da engenharia de software, por exemplo, engenharia de requisitos, design e
teste.
ü ciclo de vida, por exemplo, espiral, cascata e prototipação.
ü tipo de sistema, por exemplo orientado a objetos.
ü tamanho da organização, por exemplo, pequena (11 a 50 funcionários).
ü duração do projeto, por exemplo 1-60 horas.
ü tamanho da equipe, por exemplo, pequena (até 5 pessoas)
ü conhecimento requerido para utilizá-lo, por exemplo, especialista.
ü localização da equipe usuária, por exemplo local ou distribuída.
• Para process standard
a) Elemento tipo do standard – define se o standard é norma ou modelo.
b) Elemento palavra-chave – define as palavras-chave relacionadas ao que o process
standard trata.
• Para process patterns
a) Elemento classificação da comunidade - define a classificação da comunidade dentro
da área de engenharia de software: engenharia de requisitos, design, codificação,
teste, entre outros.
c) Elemento classificação dos problemas – define uma classificação para os problemas
abordados pelos process patterns, para a família e indivíduo: elicitar requisitos,
analisar requisitos, modelar requisitos, negociar requisitos, validar requisitos,
gerenciar requisitos, rastrear requisitos, entre outros.
68
d) Elemento descrição do contexto – define a estruturação da descrição do contexto do
process pattern em “onde acontece”, “quando acontece” e “quem são os envolvidos”.
Para implementar a idéia da “colaboração” entre tipos de processos, provendo maior
reutilização, definiu-se que todos eles deveriam ter um núcleo em comum que fosse igual
ao da instância de processo a ser gerada. Este núcleo foi definido como sendo as
“atividades detalhadas” dos processos. As atividades detalhadas são procedimentos
descritos, passo a passo, de uma atividade macro. Todos os tipos de processos deveriam
ter atividades detalhadas, mantendo-se para cada tipo a sua nomenclatura equivalente a
“atividade detalhada” que fizesse sentido dentro de sua conceituação. Por exemplo, em
um process standard fica mais adequado e genérico chamar a atividade detalhada de item
está mais próximo da linguagem dos standards. Sendo assim, a nomenclatura adotada
para o núcleo em cada tipo de processo foi:
ü Atividade detalhada para usual process,
ü item para process standard e
ü componente para process pattern
O núcleo possui, na sua essência, os seguintes elementos:
Nome (composto por ação, objeto e sinônimo)
Pré-condição
Entrada
Descrição (pode aparecer com outros nomes)
Saída
Pós-condição
Quando se definir um processo, considerando a aquitetura proposta, a instância pode ser
composta de “atividades detalhadas”, provenientes de qualquer um dos tipos de
processos. Isto só é possível pois o usual process (instância) possui um núcleo igual ao
dos outros tipos de processos.
Sabendo-se que a instância de processo a ser gerada é do tipo usual process, tem-se que:
69
ü todos os elementos de um usual process podem ser reutilizados e armazenados
diretamente8 na instância de processo;
ü para os process standards e os process patterns somente os elementos do núcleo do
processo, conforme definido anteriormente, e o nome da subseção (no process
standard) e o nome do process pattern família ou indivíduo (no process pattern) –
que são equivalentes ao nome da atividade macro no usual process – podem ser
diretamente reutilizados e armazenados na instância de processo. Veja o “De è Para”
da reutilização de um process pattern para a instância do processo (usual process):
PROCESS PATTERN – FAMÍLIA/INDIVÍDUO INSTÂNCIA USUAL PROCESS – ATIVIDADE MACRO
Nome Família/Indivíduo Nome atividade macro
PROCESS PATTERN – COMPONENTE INSTÂNCIA USUAL PROCESS – ATIVIDADE
DETALHADA
Nome componente (ação, objeto e sinônimos) Nome atividade detalhada (ação, objeto e sinônimos)
Pré-Condição Pré-Condição
Entrada Entrada
Recomendação* Descrição*
Restrição Restrição
Saída Saída
Pós-Condição Pós-Condição
* Como mencionado alguns elementos podem ter nomes diferentes, embora sejam equivalentes.
Na tabela acima, verifica-se que um process pattern família ou indivíduo tem
determinados elementos. Por exemplo, o “Nome componente” e a “Entrada”. Cada um
destes elementos quando passados, através da reutilização, para a instância do processo
serão armazenados em elementos equivalentes da instância (tipo usual process). Por
exemplo, o elemento “Nome componente” tem como elemento equivalente na instância o
elemento “Nome atividade detalhada”. O process pattern possui outros elementos, no
entanto, somente estes apresentados na tabela é que possuem equivalência direta na
8 Diretamente significa que os elementos do processo possuem uma equivalência um para um na instância
de processo, e com o auxílio de uma ferramenta, podem ser automaticamente reutilizados e armazenados na
instância de processo.
70
instância de processo. Embora somente estes elementos possam ser reutilizados
diretamente, qualquer outra informação de outros elementos pode ser reutilizada
“manualmente” através de uma cópia e colagem.
A seguir, descreve-se a linguagem de modelagem de processos mostrando-se
parcialmente o esquema de cada tipo de processo, detalhando-se os seus elementos.
Mostram-se os diagramas do esquema – uma representação da estrutura hierárquica dos
documentos XML. As DTDs (gramáticas) que especificam as linguagens, definidas
usando a meta-linguagem XML, são apresentadas no Anexo A. No mesmo Anexo, uma
seção explica como são definidas as declarações de elementos e atributos na meta-
linguagem e exemplos de documentos XML ilustram o uso das DTDs.
LINGUAGEM DE MODELAGEM DO USUAL PROCESS
Cada tipo de processo foi descrito considerando suas características e objetivando-se
manter um núcleo comum entre eles. A modelagem do usual process é central na
arquitetura proposta, pois todas as instâncias geradas, quando se realiza a reutilização, são
do tipo usual process.
O usual process está modelado em três níveis hierárquicos: o de processo, o de atividade
macro e o de atividade detalhada. Embora as atividades de um processo possam ser
descritas em vários níveis adotou-se descrevê-las nestes. Os fatos que levaram a tomar
esta decisão é que o objetivo não é a automatização dos processos; que nossa experiência
prática indica que estes níveis, são suficientes para um bom entendimento do processo e
que não é o desejo obter documentações “exaustivas”.
O diagrama na Figura 12, gerado com a ferramenta XML SPY [77], ilustra a estrutura e
os elementos (estão minimizados) da base de dados de processos. A base de processo
possui um elemento que é o usual process (BpProcesso) e outros elementos relacionados
com os processos (pode-se chamar elementos auxiliares). Dentro do elemento
BpProcesso são realizadas referências à eles, como por exemplo a indicação de
método/técnica, ferramentas e artefatos usados no processo. Os elementos da estrutura
são descritos a seguir e possuem, no diagrama, a indicação da sua cardinalidade e se são
71
opcionais (retângulo pontilhado) ou não. Posteriormente, o elemento usual process
(BpProcesso), ilustrado (Figura 13) é descrito.
Figura 12 - Diagrama da base de processo para usual process e elementos auxiliares
Elemento BaseProcesso:
Conceito: trata dos termos específicos dos processos em um determinado domínio,
necessários para o seu entendimento. Possui como elementos filho o nome do termo, o
tipo do termo (negócio ou técnico) e a descrição.
Função9: trata dos papéis envolvidos (atores) no processo, como por exemplo,
engenheiro de processos e engenheiro de requisitos. Possui como elementos filho o nome
e a descrição.
9 Função aqui descrita tem o objetivo de definir os atores envolvidos.
72
Verificação: referem-se as revisões e auditorias realizadas no processo. Possui nome,
tipo (revisão ou auditoria), descrição, frequência e quem realiza.
Medição: conjunto de definições, métodos e atividades utilizadas para medir um
processo. Possui nome, métrica (é a unidade de medição), descrição e fórmula.
Treinamento: instruções especializadas para aprimorar o conhecimento dos envolvidos
no processo, a fim de que realizem da melhor forma as atividades do processo. Possui
nome, descrição e público (alvo).
MétodoTécnica: conjunto razoavelmente completo de regras e critérios, que estabelecem
uma maneira precisa e repetitível de executar uma tarefa e chegar a um resultado
desejado. Possui nome, descrição (organizada em: o que é, porque utilizar, quando se
aplica e como se usa), restrição, produto gerado, referência (bibliográfica).
Ferramenta: instrumento de apoio ao processo. Possui nome e descrição.
Formulário: representa uma estrutura de um documento em branco. São conhecidos
como os templates. Possui nome, finalidade e arquivo (formulário).
Política: refere-se as diretrizes macros da organização referentes aos processos e seu uso.
Possui nome e descrição.
Artefato: insumos que são fornecidos ao processo ou produtos que são produzidos pelo
processo. Possui nome e descrição.
Elemento usual process (BpProcesso) – ilustrado na (Figura 13)
Nome: identificação do processo
Autor: criador do processo
Classificação: taxionomia segundo a norma ISO/IEC 12207 – processos fundamentais,
de apoio e organizacionais.
Natureza: propósito do processo dentro do banco de dados. Por exemplo se é um
processo criado para um projeto ou se é um framework.
Objetivo: a que se destina o processo, sua finalidade.
Descrição: uma descrição genérica sobre o que o processo faz e como, um sumário sobre
o processo.
Pré-condição: pré-requisitos para o processo iniciar.
Pós-condição: o que deve estar realizado após a conclusão do processo.
73
Figura 13 – Diagrama do elemento usual process
74
RepresentaçãoMacro: um diagrama ilustrando o processo do ponto de vista das suas
atividades macro. A representação possui um atributo (fluxo de controle – não mostrado
no diagrama) onde também se pode descrever como é a ordem, relacionamento entre as
atividades.
RepresentaçãoDetalhada: um diagrama ilustrando as atividades detalhadas do processo.
Também possui o atributo fluxo de controle.
Conformidade: indicação se o processo está em conformidade com alguma norma ou
modelo, como por exemplo CMM ou ISO/IEC 9000.
Característica: refere-se a atributos do processo, seu uso anterior e conhecimento
necessário para melhor utilizá-lo. Possui os elementos filho área, ciclo de vida, tipo de
sistema, tamanho da organização, duração do projeto, tamanho da equipe, conhecimento
requerido e localização da equipe usuária.
Política/ Conceito/ Função/ Verificação/ Medição/ Treinamento/ MétodoTécnica/
Ferramenta/ Formulário/ Entrada/ Saída: são referências aos elementos auxiliares dos
processos (descritos anteriormente).
AtividadeMacro: conjunto de tarefas ou trabalho a ser realizado. Fornece uma visão de
alto nível do que é realizado. O detalhamento das tarefas que compõem a atividade macro
está descrito na atividade detalhada.
Elemento AtividadeMacro – ilustrado na Figura 14
Nome: identificação da atividade. Seu nome está decomposto para que seja inserido na
forma de facetas – ação e objeto. Sinônimos para a ação também são inseridos.
Descrição: texto sobre o que a atividade faz e como é realizada.
Pré-condição: pré-requisitos para a atividade macro iniciar
Entrada/ Saída: são referências para o elemento artefato.
Predecessor: atividade(s) que precede(m) a atividade em questão. Referência para as
macro atividades do processo.
Pós-condição: o que deve estar realizado após a conclusão da atividade macro.
Restrição: idem ao usual process
RspNome: responsável pela execução da atividade. Referência para o elemento função.
75
MétodoTécnica: método/técnica utilizada pela atividade. Referência para o elemento
método/técnica.
Ferramenta: aplicativo utilizado pela atividade ou que a implementa. Referência para o
elemento ferramenta.
AtividadeDetalhada: procedimento detalhado da atividade macro.
Como o elemento atividade detalhada possui os mesmos elementos da atividade macro
(menos a atividade detalhada), optou-se por não descrevê-los.
Figura 14 – Diagrama do elemento atividade macro de um usual process
LINGUAGEM DE MODELAGEM DO PROCESS PATTERN
Principalmente em design patterns, existe uma grande quantidade de patterns
disponíveis. Um dos problemas que se enfrenta em reutilização é localizar um pattern
adequado e entender a sua solução. Muitos patterns são propostos individualmente e
outros vem organizados em linguagens para algum propósito específico. Portanto, ter
uma forma de classificar patterns é fundamental para a sua recuperação e uso.
76
Para organizar os process patterns definiu-se a classificação Process Patterns Society -
Sociedade de Patterns de Processo. Na descrição textual da solução dos patterns muitas
vezes aparecem vários links (ligações), como por exemplo, referências a outros patterns.
A sociedade é uma maneira de organizá-los e dar uma idéia de “matriz de
relacionamentos” entre os process patterns, facilitando a busca e o entendimento da
solução apresentada. É algo similar a um Catálogo usado em Design Patterns (coleção de
patterns logicamente organizados10) [78].
Segundo Meszaros et all [79], no artigo “A Pattern Language for Pattern Writing, a
estrutura do pattern é fundamental para que se entenda o porquê de se usar a solução
proposta e a solução do problema em si (o “como”). Também ressaltam que pessoas
muitas vezes têm um tempo limitado para investir na leitura de um pattern e, descrições
muito longas podem fazer com que o leitor desista por achar que o retorno não justifica o
investimento.
Sendo assim, neste trabalho, ao contrário de uma descrição textual única para descrever a
solução do process pattern, estruturou-se a sua descrição em componentes. Estes
componentes são equivalentes a atividades do usual process. Organizar estas atividades
em componentes tem como objetivo tornar mais claro ao leitor qual é a solução do
pattern. Essa organização define a descrição do componente (atividade), busca outros
elementos associados (entradas, saídas, entre outros) e ligações que cada um deles possa
ter com outros patterns. Dessa forma, torna-se mais evidente o que tem que ser realizado
e os elementos relacionados, por exemplo, entradas e saídas, que muitas vezes não são
descritos, dificultando o entendimento da solução.
10 O relacionamento entre os patterns forma a linguagem de patterns [36].
77
A sociedade de process patterns tem os process patterns organizados (Figura 15) da
seguinte maneira:
• Process Pattern Indivíduo: é um process pattern que possui, como característica
principal, apresentar uma solução para um problema sem fazer uso de outros patterns.
• Process Pattern Família: é um process pattern que possui, como característica
principal, uma solução para um problema composto por um ou mais patterns.
• Process Pattern Communidade: é um conjunto de process patterns, indivíduos e
famílias, de um determinado domínio.
Indivíduo
IndivíduoIndivíduo
Família
Família Família
Indivíduo
Indivíduo
IndivíduoIndivíduo
Família
Família Família
Indivíduo
Figura 15 - Process Pattern Society: organização dos process patterns
A Figura 15 mostra um exemplo de uma comunidade que possui várias famílias e
indivíduos. Os relacionamentos entre eles indicam que a solução usa outros patterns
indivíduo/ família.
A seguir ilustra-se uma comunidade com suas famílias, que são formadas por outras
famílias e indivíduos. Posteriormente visualiza-se parcialmente o conteúdo de um
indivíduo da família Construir Sistemas Certos.
78
Várias taxionomias para patterns têm sido propostas para design patterns, algumas delas
são descritas por Buschmann e Meunier [35], Ralph Jonhnson [80], Gamma et all [33],
Thomas J. Mowbray e Raphael C. Malveau [78] e Walter Zimmer [81]. Para process
79
patterns, a mais estruturada é de Scott Ambler [21]. No entanto, essa proposta está muito
restrita ao processo de desenvolvimento de software como um todo e não segue os
templates estabelecidos pela comunidade de patterns [33] [67]. Ambler classifica seus
patterns em três tipos:
• Process pattern tarefa (task process pattern): descreve os passos detalhados para
realizar uma tarefa específica, tal como o pattern Revisões Técnicas.
• Process pattern estágio (stage process pattern): descreve os passos que são muitas
vezes realizados interativamente, em um único estágio do projeto. Um pattern deste é
apresentado para cada estágio do projeto, tal como o Estágio Modelo.
• Process pattern fase (phase process pattern): descreve as interações entre os patterns
de processo estágio para uma única fase do projeto. Por exemplo a Fase Inicial e a
Fase Construção.
Por outro lado, Whitenack [26] e Copplien [58], utilizam os templates estabelecidos pela
comunidade para descrever originalmente os design patterns e, em ambos, a solução é
uma descrição textual linear, sem estruturação.
Um process pattern está organizado em comunidade, família e indivíduo, dentro da sua
sociedade de process patterns. A diferença básica entre a modelagem da família e do
indivíduo é que a solução do pattern família faz referência a outros patterns indivíduos
ou mesmo outras famílias. A solução, que é composta de componentes, é o núcleo
comum entre os tipos de processo e o que será reutilizado. As outras informações do
process pattern são mais um auxílio na localização do pattern desejado e na verificação
das similaridades do contexto do referido process pattern com o contexto de quem
reutiliza. A seguir, apresenta-se o diagrama da process pattern society – comunidade
(Figura 16), família (Figura 17), e da solução do process pattern (componente) – Figura
18.
80
Figura 16 – Diagrama do elemento process pattern society – comunidade
Elemento Process Pattern Comunidade:
Nome: identificação do process pattern comunidade.
Palavras-chaves: palavras que podem auxiliar na busca de uma comunidade de process
patterns. Estão relacionadas ao problema abordado pela comunidade.
Origem: criador da comunidade process pattern – na literatura pode-se relacionar com
criador(es) da linguagem de process pattern em questão. Podem ser pessoas e/ou
organizações.
Finalidade: o objetivo da comunidade de process pattern.
Classificação: classifica a comunidade dentro das áreas da engenharia de software
(engenharia de requisitos, design, construção, teste, implantação, manutenção).
81
Problema: descreve quais são os problemas, dificuldades, que a comunidade de process
patterns visa tratar.
Contexto: em quais situações os problemas acontecem (recorrem). “Pode-se pensar que é
a configuração inicial de um ambiente antes de o pattern ser aplicado” [56]. A descrição
do contexto está estruturada em onde acontece, quando acontece e quem são os
envolvidos.
Causa: a descrição das forças (complicações) e restrições dos problemas e como elas
interagem/ conflitam umas com as outras.
Representação: diagrama mostrando as relações entre as famílias e indivíduos da
comunidade.
Artefatos: insumos que são fornecidos ao processo ou que são produzidos pelo processo.
Possui nome e descrição.
Como descrito, um elemento process pattern comunidade pode ser composto de process
pattern famílias e process pattern indivíduos. A seguir (Figura 17) descreve-se o process
pattern família.
Figura 17 – Diagrama do elemento process pattern família
Elemento Process Pattern Família:
Identificação: Nome da família. Possui, para auxiliar na busca, palavras-chave e uma
classificação para os problemas tratados pelo process pattern (por exemplo, elicitação de
requisitos, análise de requisitos, negociação de requisitos, modelagem de requisitos,
validação de requisitos, gerenciamento de requisitos, rastreamento de requisitos e
métodos/técnicas de engenharia de requisitos).
82
Contexto: idem a descrição em comunidade
Causa: idem a descrição em comunidade
Controle: descrição dos controles realizadas sobre o pattern. Pode ser por exemplo,
medições, verificações (check-lists).
PatternRelacionado: referência textual a process patterns relacionados ao assunto e que
não necessariamente estão cadastrados na base, por exemplo, estão na literatura.
Representação: diagrama provendo a visualização dos componentes da solução e seus
relacionamentos com outras famílias e indivíduos.
Solução:
A solução é formada de componentes, que são equivalentes as atividades detalhadas de
um usual process. O diagrama a seguir (Figura 18) mostra a estrutura dos componentes
da solução de um process pattern família. Esta estrutura é a mesma para a solução de
process pattern indivíduo, com exceção do último item (UsaPattern) que somente é
aplicado à família. Lembrando, um process pattern família é assim chamado pois um ou
mais componentes da sua solução podem ser outros process patterns.
Figura 18 – Diagrama do elemento Componente da solução de um proc. pattern família
83
Elemento Componente – Process Pattern Família:
Nome: identificação do componente. O nome está decomposto nas faceta ação e objeto.
Possui também sinônimos. É uma parte (equivalente a uma atividade) da solução do
problema.
Pré-condição: pré-requisitos para o processo iniciar.
Entrada: insumos para o componente. Faz referência para os artefatos da comunidade.
Recomendação: descrição fornecida pelo componente do pattern sobre uma atividade
que deve ser realizada para solucionar o problema.
Restrição: limitações do componente.
Saída: produtos gerados pelo componente. Faz referência para os artefatos da
comunidade.
Pós-condição: o que deve estar pronto após o uso do componente.
UsaPattern: uma lista de referências para outros PatternsUsado (indivíduos e famílias da
comunidade em questão).
Elemento Process Pattern Indivíduo
O elemento process pattern indivíduo é igual ao elemento process pattern família. A
única diferença é que no process pattern indivíduo o elemento componente não tem o
elemento filho UsaPattern.
LINGUAGEM DE MODELAGEM DO PROCESS STANDARD
Devido a diversidade de formatos de padrões (standards – normas e modelos), foi preciso
encontrar uma forma que se pudesse representá-los em um process standard, sem perder
a sua “estrutura semântica”. Também precisava-se ter o núcleo comum aos outros tipos
de processos. Como mencionado, a grande maioria dos standards pode ser representado
em três níveis [70]. Desta forma, adotou-se para a estrutura de um process standard o
nível seção, subseção e item. As seções referem-se mais a estrutura do padrão e o item
refere-se às práticas a serem realizadas – atividades. A seguir, apresenta-se o diagrama de
um process standard com seus elementos (Figura 19).
84
Na descrição dos elementos, alguns deles se referem ao padrão original e não ao process
standard, como por exemplo, autor e versão do modelo/ norma.
Figura 19 – Diagrama minimizado do process standard
Elemento Process Standard:
Nome: identificação do process standard.
PalavraChave: palavras-chave relacionadas com o process standard.
Objetivo: a que se propõe o process standard.
Aplicabilidade: onde o process standard pode ser aplicado, em que situações.
Tipo: como o padrão pode ser classificado (modelo ou norma).
Descrição: uma introdução ao process standard.
85
Autor: responsável (pessoa ou organização) pela criação do padrão.
Versão: versão do padrão.
Representação: diagrama provendo a visão geral do process standard.
OndeEncontrar: onde pode-se ter acesso ao padrão.
Adaptação: como o padrão pode ser adaptado.
Artefatos: insumos que são fornecidos ao processo ou que são produzidos pelo processo.
Possui nome e descrição.
Conceitos: termos específicos do domínio do process pattern. Possui como elementos
filhos o nome, tipo do termo (negócio ou técnico) e a descrição.
Função: papéis envolvidos no processo. Possui como elementos filho o nome e a
descrição.
Seção: uma seção pode ser uma divisão organizacional macro ou uma classificação
dentro do padrão. Por exemplo, no process standard CMM, a seção é o nível do CMM
(por exemplo nível 2). A seguir (Figura 20), apresenta-se o diagrama da estrutura da
seção.
Figura 20 – Diagrama do elemento seção de um process standard.
Elemento Seção:
Nome: identificação da seção.
Objetivo: finalidade da seção.
Descrição: um sumário do que a seção trata.
Subseção: uma subseção, igualmente a seção, pode ser um divisão organizacional
detalhada ou classificação dentro do padrão. Por exemplo, no CMM, uma subseção da
86
seção Nível 2 é Gerenciar Requisitos. A seguir (Figura 21), apresenta-se o diagrama da
estrutura da subseção.
Figura 21 – Diagrama do elemento subseção de um process standard
Elemento Subseção:
Nome: identificação da subseção.
Referência: uma indicação para a subseção, na forma de sigla ou numeração. Por
exemplo, Gerência de Requisitos tem a referência GR. Quando possível utiliza-se a
própria referência do padrão original.
Objetivo: finalidade da seção.
Descrição: um sumário da seção - o que aborda.
Representação: um diagrama do padrão na forma de processo.
Treinamento: lista de treinamentos – instruções especializadas para aprimorar o
conhecimento dos envolvidos no processo, a fim de que realizem da melhor forma as
atividades do processo.
Verificação: conjunto de verificações (revisões e auditorias) realizadas no processo.
Possui nome, tipo (revisão ou auditoria), descrição, frequência e quem realiza.
87
Medição: conjunto indicado de definições, métodos e atividades utilizados para medir
um processo.
Ferramenta: instrumentos indicados de apoio ao processo.
Observa-se que os elementos treinamento, verificação, medição e ferramenta também
existem no usual process. Embora eles não possam ser reutilizados diretamente, podem
contribuir para a definição deles na instância.
Item
São práticas, equivalentes as atividades detalhadas do usual process, que devem ser
realizadas para atender ao padrão (Figura 22).
Figura 22 – Diagrama do elemento Item de um process standard
Elemento Item:
Nome: identificação do item. Está desmembrado em ação, objeto e possui sinônimo.
Referência: uma indicação para o item, na forma de sigla ou numeração.
Pré-condição: pré-requisitos para iniciar a definição do item.
Entrada: insumos para o item. Faz referências para os artefatos do process standard.
Descrição: descrição do que deve ser realizado para atender ao item em questão.
Restrição: limitações impostas ao item em questão.
88
Saída: produtos gerados pelo item. Faz referência para os artefatos do process standard.
Pós-condição: o que deve estar pronto após cumprir o item.
Responsável: pessoa ou organização responsável pelas tarefas do item. Referência para o
elemento função.
RESUMO
Neste capítulo salientou-se a pesquisa [75] que relatou que ainda não existe experiência
suficiente de como modelar processos descritivamente. Descreveu-se sobre trabalhos
anteriores, em processos de negócio e mapeamento de processos do CMM, que foram que
foram motivadores dessa tese. Entretanto, para ter uma arquitetura para processos visando
a reutilização, percebeu-se que novos aspectos deviam ser considerados. Sendo assim,
aspectos ligados a própria natureza da atividade de reutilização, como por exemplo,
classificação e recuperação, foram considerados. Também foram definidos elementos
para os diferentes tipos de processos, de tal forma que pudessem auxiliar na classificação
e busca das informações. Exemplos são a classificação do usual process segundo a
ISO/IEC 12207 e a sociedade de process patterns.
Procurou-se também salientar aspectos de “colaboração”, ou seja, de como cada tipo de
processo poderia colaborar com informações para a construção de uma instância de um
processo. Sendo assim, um núcleo comum entre os tipos de processos foi estabelecido
definindo-se que cada um deles deveria ter, no nível “atividades detalhadas”, os seguintes
elementos: nome, descrição, entradas, saídas e pré/ pós-condições. Desta forma, uma
instância pode ser formada, quando da reutilização, de atividades provenientes de
qualquer um dos tipos de processos estabelecidos.
Uma instância de processo é do tipo usual process, portanto todos os elementos dos
processos do tipo usual podem ser reutilizados e armazenados diretamente para a
instância do processo. Mas, para os processos do tipo standard e patterns, somente o
núcleo (que é equivalente a atividade detalhada) e, o nome da subseção (no process
standard) e o nome do process pattern família ou indivíduo (no process pattern) – que
89
são equivalentes ao nome da atividade macro no usual process – podem ser reutilizados
diretamente. Entretanto, cópia e colagem (copy and paste) de dados pode ser realizada
sempre que se achar conveniente.
Apresentou-se também a especificação dos tipos de processos, através de diagramas
(esquema) com elementos e descrição. Para que as linguagens de processos não ficassem
rígidas optou-se em se ter elementos do processo opcionais. Na definição da linguagem,
organizou-se o usual process em três níveis: o de processo, o de atividade macro e o de
atividade detalhada. Embora as atividades de um processo possam ser descritas em vários
níveis, adotou-se descrevê-las nestes. Isto se deve aos fatos que o objetivo não é a
automatização dos processos; que nossa experiência prática indica que estes são
suficientes para um bom entendimento do processo e que não é o desejo ter
documentações “exaustivas”. Um process pattern, por sua vez, está organizado na sua
sociedade de patterns em comunidade, família e indivíduo. A diferença básica entre a
definição da família e indivíduo é que a solução do pattern família faz referência a outros
patterns indivíduos ou mesmo outras famílias. A solução do process pattern, que é
composta de componentes, é o núcleo comum entre os tipos de processo. Finalmente para
o process standard, devido a diversidade de formatos de standards, foi preciso encontrar
uma forma que se pudesse representá-lo, sem perder a “estrutura semântica” dos
standards originais. Como a maior parte destes pode ser modelada em três níveis, adotou-
se o nível seção, subseção e item. As seções referem-se mais a estrutura do standard e o
item refere-se as práticas a serem realizadas – atividades – que é o núcleo comum entre
os tipos de processos.
90
Capítulo 5 – Desenvolvimento de Frameworks de Processos
Este capítulo apresenta a forma adotada para desenvolver um framework de processo,
abordando elementos da arquitetura proposta, e a compara com um processo de
desenvolvimento de frameworks de aplicação. Descreve-se como foi realizada a análise de
domínio, através de matrizes de generalização de atividades, e descreve-se a montagem do
framework, utilizando os guias de reutilização de processo. Apresenta-se um exemplo, parcial,
de um framework de processo para engenharia de requisitos e as principais dificuldades na sua
elaboração.
FRAMEWORK DE PROCESSO
Quando se pensa em framework de processos, pode-se imaginar frameworks genéricos ou
mais específicos, voltados para a implementação. Tipicamente, os frameworks de
processos de domínios maduros (amplamente praticados e conhecidos), podem ser
orientados à implementação. Exemplos dos processos orientados à implementação são
àqueles descritos no SAP/R3 [2], tais como, vendas e distribuição, gerência de materiais e
planejamento da produção. No entanto, para processos que ainda não atingiram sua
maturidade, geralmente fica difícil descrevê-los em detalhes, especificando-se caminhos
alternativos, tal que possam ser implementados e adaptados de acordo com as situações
pré-definidas no processo. Os frameworks baseados nestes processos denominamos
frameworks genéricos.
Quanto mais imaturo e mais abstrato for o domínio, maior é a dificuldade de definição de
um framework, pois geralmente existe uma grande diversidade de modelos de processos,
dificultando o estabelecimento de pontos comuns entre eles. Exemplos de processos que,
em sua grande maioria, ainda não alcançaram a sua maturidade são os de engenharia de
software. Segundo Loucopoulos e Karakostas [82], no processo de engenharia de
requisitos “métodos contemporâneos de software não prescrevem um processo de
engenharia de requisitos formal. A maior parte deles focam nas saídas dos processos
(produtos), ao invés do processo propriamente dito. Tal incapacidade e dificuldade
aparente de fornecer uma descrição formal do processo de engenharia de requisitos
explicam a proliferação de modelos de requisitos”. Kotonya e Sommerville [83] também
relatam este problema.
91
Segundo Paulk et all [17], maturidade do processo de software é definida como sendo a
“extensão para o qual um processo específico é definido, praticado, gerenciado, medido e
controlado”. Pesquisas [41] relatando o nível de maturidade das organizações quanto aos
seus processos de software, demonstram que eles ainda são imaturos. Neste trabalho,
abordam-se frameworks de processos genéricos, visto que nossa área de interesse é
processos de engenharia de software, mais especificamente engenharia de requisitos.
Sendo assim, questões de implementação de processo não são consideradas.
Em processos orientados à implementação, que se parecem mais com os frameworks de
aplicação, a identificação dos pontos de flexibilização fica mais clara, e caminhos
alternativos na execução do processo podem ser encontrados. No entanto, em processos
genéricos, seus pontos de flexibilização geralmente são definidos pelas atividades que
podem fazer parte ou não do processo. Na maioria das vezes, a inclusão de atividades
amplia mais o escopo do processo ou o detalha mais em profundidade. Os caminhos
alternativos dos processos, nestes frameworks, se dão pela escolha, por exemplo, de
determinados métodos/ técnicas, em função das necessidades correntes. Portanto, no
contexto destes frameworks de aplicação são apresentados os métodos/ técnicas e em que
situações eles devem ser aplicados.
Com o objetivo de se criar um framework, escolheu-se sete processos de engenharia de
requisitos [82] [83] [84] [85] [86] [87] [88], na literatura corrente, por ser a área que se
encontrava com material disponível e experiência de pesquisa. Outro ponto que foi
considerado é que processos de requisitos são desejados em processos de certificação de
software, como, por exemplo, CMM e ISO, podendo-se então avaliar o uso conjunto com
os process standards.
Para iniciar o desenvolvimento de um framework é necessário escolher um processo para
realizar esta tarefa. Os processos de desenvolvimento de frameworks de aplicação, por
exemplo [34], começam definindo o modelo de objetos de algumas aplicações e, através
de comparações entre elas, determinam-se os pontos comuns. Entretanto, a forma como
92
esta comparação é realizada raramente é descrita [89]. Como o objetivo deste trabalho é
framework de processos, utilizou-se o processo de Pree [34] com algumas adaptações e
detalhamentos que não estavam descritos na sua proposta. A Tabela 3 compara o
processo de Pree, para frameworks de aplicação, e a nossa proposta para frameworks de
processos. Utiliza-se a tabela de Pree, mesmo considerando a grande diferença com a
nossa proposta, pois o seu processo de desenvolvimento de frameworks é amplamente
conhecido e citado na área e, por não contarmos com um processo de desenvolvimento de
frameworks de processos na literatura.
PREE [34] Proposta para frameworks de processo Definir Modelo de Objetos do Domínio Elicitar processos
Gerar o modelo de processos Definir Matriz de generalização das atividades Definir pontos comuns
Identificar os hot-spots Definir características (features) Re(Projetar) o framework Montar o framework
Montar guias de reutilização Adaptar o framework Adaptar o framework
Tabela 4 – Comparação do processo de desenvolvimento de frameworks de Pree com a
proposta para processos
As propostas diferem no objeto manipulado (utilizam-se processos) e no detalhamento
dos dois primeiros itens, onde é descrito em mais detalhes como foi realizada a análise
dos processos no domínio e onde é realizada a identificação dos pontos comuns e
variáveis dos processos. Utilizaram-se também as características e os guias de
reutilização. Estes últimos tem similaridade com a proposta do hot spot cards.
O principal objetivo do desenvolvimento de frameworks é identificar seus pontos comuns
e de flexibilização (hot-spots). A forma básica para isto é a comparação entre aplicações,
no caso de frameworks de aplicação, e comparação entre atividades, no caso de
frameworks de processo. Sendo assim, definiu-se atividade específica para realizar a
análise e comparação das atividades (macro e detalhada) dos processos. Estas atividades
estão descritas no processo de desenvolvimento de frameworks de processos, descrito a
seguir.
93
5.1.1 PROCESSO DE DESENVOLVIMENTO DE FRAMEWORK DE PROCESSO
Descrevemos o processo de desenvolvimento de frameworks utilizando parcialmente a
linguagem de modelagem de processos de um usual process proposta nesta tese.
PROCESSO DE DESENVOLVIMENTO DE FRAMEWORK DE PROCESSO
Autor Soeli Fiorini/ Julio C.S.P. Leite
Natureza Processo base
Objetivo Demonstrar como se realiza o estudo/ a definição de domínio para
definir um framework de processos.
Descrição Para definir o framework, inicialmente é preciso coletar e descrever
processos (alguns) do domínio escolhido, em uma linguagem de
modelagem de processos. As atividades destes processos serão então
comparadas e rotuladas para que seja possível definir pontos comuns,
características e pontos de flexibilização do processo. Isto é realizado
definindo-se uma matriz de generalização das atividades. Uma vez
que as atividades comuns tenham sido identificadas estas devem ser
documentadas como um usual process e os guias de reutilização
devem ser montados. Finalmente, o framework deve ser reutilizado
para verificar o que deve ser melhorado.
Função Responsável Engenheiro de domínio/ processos
Entradas Processos do domínio.
Saídas Framework, guias de reutilização, matrizes de generalização das
atividades.
Atividade macro ELICITAR PROCESSOS
Descrição Inicialmente, deve-se identificar as possíveis fontes onde os processos
podem ser encontrados para selecionar um conjunto de processos a
serem utilizados como a base da construção do framework. Algumas
considerações, quando possível, devem ser tomadas. Por exemplo,
processos que tenham descrições mais completas com relação a
linguagem de modelagem devem ser preferidos. Processos que tenham
a estrutura hierárquica definida também reduzem o trabalho de
94
mapeamento. Certifique-se dos objetivos dos processos para ter um
escopo similar. Processos com similaridades (por exemplo, ciclo de
vida ou se está descrito com base em técnicas ou não) garantem um
número maior de atividades comuns e facilitam a comparação.
Entrada Processos do domínio
Saída Processos selecionados
Responsável Engenheiro de domínio/ processos
Atividade macro GERAR O MODELO DE PROCESSOS
Descrição Inicialmente, cada processo que será analisado para desenvolver o
framework deve ser descrito e documentado na linguagem de
modelagem de um usual process. Todos processos devem ser do tipo
usual process. O objetivo é ter uma linguagem única, de tal forma que
os processos possam ser comparados.
Entrada Processos do domínio, linguagem de modelagem do usual process
Saída Modelos de processos
Responsável Engenheiro de domínio/ processos
Atividade macro DEFINIR MATRIZ DA GENERALIZAÇÃO DE ATIVIDADES
Descrição O objetivo é criar uma matriz (tabela) com as atividades dos processos
selecionados e compará-las. Durante a comparação, as atividades são
rotuladas para identificar àquelas que são comuns ou não aos
processos analisados do domínio.
Entrada Modelos de processos
Saída Matriz de generalização de atividades
Responsável Engenheiro de processos
Atividade detalhada CRIAR MATRIZ COM ATIVIDADES
95
Descrição O objetivo da matriz é identificar pontos (atividades) entre os
processos que sejam comuns. O matriz, em forma de tabela, é
construído com base nos processos selecionados e modelados e nas
facetas de “ação” e “objeto” das atividades macro e detalhada, de cada
um deles. Inicialmente, deve ser elaborada a matriz com a visão geral
dos processos, apresentando suas macro atividades.
A coluna vertical é reservada para os nomes dos processos (o autor
pode ser incluído para diferenciar processos com nomes iguais) e a
horizontal contém as atividades (veja a tabela - matriz abaixo). Para
dar início, somente a primeira coluna contém atividades, na
horizontal, de um processo chamado “base”. Um processo “base”, é
um processo que foi escolhido para ser o ponto de partida para as
comparações. Veja a matriz inicial de generalização das atividades:
Processo x(Base)
Processo z Processo k Processo wProcesso y
Atividade A
Atividade B
Atividade C
Atividade D.
Entrada Modelo de processos
Saída Matriz de generalização das atividades com processo base
Responsável Engenheiro de processos
Atividade detalhada COMPARAR ATIVIDADES
Descrição Uma atividade do processo base é escolhida, marcada com uma seta,
informando que ela é uma atividade base (matriz anterior – Atividade
A). Esta é comparada com as outras atividades dos outros processos,
no mesmo nível, por exemplo, atividade macro. Compara-se a “ação”
e o “objeto” da atividade base com a “ação” e o “objeto” das outras
atividades dos outros processos. Por exemplo, a atividade base
“elicitar (ação) requisitos (objeto) é comparada com a atividade
“adquirir (ação) conhecimento (objeto)” de outro processo.
96
Entrada Matriz de generalização das atividades com processo base
Saída Lista de atividades iguais (ação e objeto) ou similares a atividade base.
Responsável Engenheiro de processos
Atividade detalhada ROTULAR AS ATIVIDADES
Descrição Cada atividade que possuir uma “ação” ou um “objeto” igual ou, uma
“ação” ou “objeto” sinônimo ao da atividade base recebe um rótulo.
Cada atividade pode ter dois rótulos referindo-se a ação e objeto. A
legenda a seguir mostra os rótulos, sendo que para o último (bolas
brancas) não são apresentadas as combinações possíveis com os outros
rótulos:
A O
A S
S S
OS
Ação e Objeto iguais
Ação igual e Objeto sinônimo
Ação sinônimo e Objeto igual
Ação sinônimo e Objeto sinônimo
Ação Objeto com alguma similaridade
Aplica-se o rótulo em branco (sem letra) quando a atividade analisada
é similar à atividade base, embora não tenham facetas iguais ou
sinônimos. Utiliza-se “—“ quando a atividade não tiver nenhuma
referência em outro(s) processo(s). Para se determinar o rótulo
também se consideram as descrições das atividades e suas atividades
detalhadas.
Após percorrer todos os processos das colunas verticais, deve-se
retornar ao processo base escolhendo outra atividade, comparando-a e
rotulando-a como descrito. Isto se repete até que se passe por todas as
atividades do processo base.
Entrada Matriz de generalização com as atividades comparadas
Saída Atividades rotuladas
Responsável Engenheiro de processos
Atividade detalhada SELECIONAR ATIVIDADES NÃO ABORDADAS PELO PROCESSO
BASE
97
Descrição Finalizadas as atividades do processo base, passa-se para o processo à
direita do processo base. Escolhe-se uma atividade do processo que
ainda não possui comparação e marca-se com uma seta (veja na matriz
que segue a Atividade L, por exemplo). Segue-se da mesma forma
descrita anteriormente, comparando-as e rotulando-as até finalizarem
as atividades do processo (veja o exemplo que segue com a
comparação de atividades). Percebe-se que este processo (Processo y)
virou o processo base. Continua-se nesta atividade, selecionando-se as
próximas atividades não abordadas, até finalizarem os processos da
matriz.
Processo x(Base)
Processo z Processo k Processo wProcesso y
Atividade A
Atividade B
Atividade C
Atividade D
Atividade aa Atividade ax Atividade az Atividade rr
Atividade bb
Atividade cc
Atividade dd
Atividade xb
Atividade L Atividade zz
Atividade xx
Atividade di
Atividade cc
Atividade di Atividade di
Atividade ii Atividade ai
Atividade K Atividade kiA O
A OA O
A O
A O
A O
OS
A S
S S
S S
S S
A O
OS
OS
Entrada Matriz de generalização de atividades rotulada
Saída Matriz de generalização de atividades completa
Responsável Engenheiro de processos
Atividade macro DEFINIR OS PONTOS COMUNS
Descrição Para cada atividade base (marcada com a seta), define-se uma
pontuação. Conta-se um ponto quando a atividade base possuir outra
atividade analisada com “ação” e “objeto” igual (rótulo com a letra A
e rótulo com a letra O), ou “ação” e/ou “objeto” sinônimo (rótulo com
a letra S) ou for similar.
1 Ponto = (ação atividade base = ação atividade analisada) e (objeto
atividade base = objeto atividade analisada) ou
1 Ponto = (ação atividade base = ação-sinônimo atividade analisada) e
(objeto atividade base = objeto atividade analisada) ou
1 Ponto = (ação atividade base = ação atividade analisada) e (objeto
atividade base = objeto-sinônimo atividade analisada)
98
1 Ponto = (ação atividade base = ação-sinônimo atividade analisada) e
(objeto atividade base = objeto-sinônimo atividade analisada)
Assim, considera-se que uma atividade é comum a uma atividade base
x se ela apresentar “ação” e “objeto” iguais, ou apresentar “ação” e/ou
“objeto” sinônimos da “ação” e “objeto” da atividade base x. Embora
esta seja a regra, sempre é necessário a intervenção humana para
verificar se realmente as descrições são similares. Considera-se similar
se na essência as atividades possuem o mesmo desejo de fazer algo,
embora possam ter alguma variação de escopo e/ou descrição11.
Considera-se a atividade analisada comum se ela também for similar a
atividade base. Neste caso também se computa 1 ponto. Geralmente é
necessário fazer esta avaliação mais rigorosa quando a “ação” e o
“objeto”, ou um deles, forem sinônimos da atividade base e quando
tiverem nomes diferentes (bola branca). A pontuação de cada
atividade base (PAb) é computada somando-se as atividades comuns da
atividade base (ACAb) ou seja: PAb = Σ ACAb
No entanto, uma atividade só é comum a maioria dos processos no
domínio se apresentar pelo menos 75% de pontos com relação a sua
“repetição” dentro do domínio, ou seja, a atividade se repete em pelo
menos 75% dos processos analisados. Para ter o percentual da
atividade base usa-se:
PercentualAb = (PAb x 100) / NumProcAnalisados.
As atividades comuns representam a generalização no domínio. Não
se utiliza “100%”, pois isto restringiria em muito a definição de
pontos comuns, visto que os processos são genéricos, ou seja, não
estão totalmente bem definidos, sendo difícil encontrar atividades
comuns que se repetem em todos os processos analisados do domínio.
Para cada atividade macro (marcada com uma seta), identificada como
comum, cria-se uma matriz. Para criar a matriz seguem-se os mesmos
passos apresentados. Entretanto, agora a matriz tem uma atividade
11 Percebe-se que é quase impossível encontrar duas descrições exatamente iguais.
99
macro base e suas atividades detalhadas é que são comparadas (antes
se tinha o processo e suas atividades macros é que eram comparadas).
Entrada Matriz de generalização de atividades completa
Saída Atividades comuns identificadas
Responsável Engenheiro de processos
Atividade macro DEFINIR CARACTERÍSTICAS
Descrição Com base na pontuação definida é possível, de forma determinística,
indicar características para cada atividade. Considera-se que uma
atividade:
• É [E]ssencial no domínio: se a atividade obtiver uma
pontuação igual ou superior a 75%12 em relação ao número de
processos analisados.
• É [REC]omendável que seja abordada: se a atividade obtiver
uma pontuação menor ou igual a 74% e maior ou igual a 50%.
Pela análise percebe-se que a atividade é importante, no
entanto só alguns processos mais recentes, que refletem a
maturidade de algumas pesquisas, as abordam.
• Deve ser [AN]alisada: se a atividade obtiver uma pontuação
menor que 50% e maior ou igual a 25%.
• É [ES]pecífica de alguns processos: se a atividade obtiver uma
pontuação menor que 25%.
Do ponto de vista da reutilização, acima de 75% as atividades são
comuns [CO] na maioria dos processos, e abaixo deste percentual, elas
são opcionais [OP], ou seja, menos comuns em processos do domínio.
Portanto, estas últimas possuem uma probabilidade de serem menos
reutilizadas. O que deverá determinar o seu uso serão necessidades
específicas da organização.
Sem fazer uso da pontuação determinística, mas baseada na análise,
12 Conforme descrito anteriormente não se utiliza “100%”, pois isto restringiria em muito a definição de
pontos comuns, visto que os processos são genéricos, ou seja, não estão totalmente bem definidos, sendo
difícil encontrar atividades comuns que se repetem em todos os processos analisados do domínio.
100
utiliza-se a característica implícita [IM] e fora [FO] (aplicada para as
atividades detalhadas).
• [IM]plícita: para indicar que a atividade geralmente está
implícita em muitos processos, embora não esteja definida
neles, explicitamente, como uma atividade. Por exemplo, a
atividade “Coletar Fatos” muitas vezes está implícita em
textos como “consultar stakeholders” ou “elicitar informações
de usuários finais, clientes, ..”.
• [FO]ra: para indicar que a atividade detalhada tem uma ou
mais referências fora da sua atividade-macro ou está em um
nível (macro ou detalhado) diferente de descrição, ou seja, a
atividade em questão encontra uma outra similar em outra
atividade-macro ou é uma outra atividade-macro. Por
exemplo, a atividade macro “Elicitar Requisitos” contém a
atividade detalhada “Comunicar Cliente”, no entanto esta
mesma atividade aparece como sendo uma atividade macro
em outro processo, com o sinônimo “Negociar com Cliente”.
Muitas das características apresentadas indicam “níveis” de
flexibilização das atividades e são dicas que o engenheiro de
processos deve observar para tomar decisões no momento da
instanciação do framework.
Entrada Matriz de generalização de atividades completa
Saída Características de cada atividade identificadas
Responsável Engenheiro de processos
Atividade macro MONTAR O FRAMEWORK
Descrição O framework é um usual process da natureza “framework”. As
atividades (macro e detalhadas) marcadas com uma seta, na matriz,
serão pontos comuns [CO] ou pontos de flexibilização [OP] no
framework. Portanto, baseando-se nas matrizes de generalização e nas
características definidas para as atividades, seleciona-se as atividades
comuns (CO) e essenciais (E) macro e suas atividades detalhadas. Ser
um ponto comum indica que o nome da atividade deve existir na
101
definição do processo (instância), entretanto suas descrições, se
necessário, podem ser complementadas. As atividades devem ser
descritas na linguagem de modelagem de um usual process, definindo
entre outras suas interfaces (entradas e saídas) e descrições. Os outros
elementos do processo (métodos, ferramentas ...) também são
definidos. As atividades opcionais (OP) macro e detalhadas são
cadastradas no processo, com descrições default para que sejam
preenchidas quando da geração da instância do processo.
Entrada Matriz de generalização de atividades completa, características e
atividades comuns identificadas, linguagem de modelagem do usual
process.
Saída Framework documentado
Responsável Engenheiro de processos
Atividade macro MONTAR GUIAS DE REUTILIZAÇÃO
Descrição Para definir o guia do framework, são selecionadas as atividades
macros que fazem parte dele. Baseando-se nas matrizes de
generalização, para cada atividade macro comum e opcional são
definidas no guia, com base na matriz, as colunas de características e
componentes “substitutos” das atividades. Os componentes referem-se
aquelas atividades macros que possuem facetas (nome e objeto) iguais
ou sinônimos da atividade em questão, ou que são similares. Eles
serão utilizados para preencher as descrições das atividades opcionais
e complementares as atividades comuns (se desejado). Ao montar o
guia deve-se também definir que process standards e que process
patterns o guia estará abordando. Escolhido, identificam-se os itens
dos process standards e os process patterns associados a cada
atividade. Neste caso o engenheiro de processos deve verificar, na
base de dados de processos existentes, para cada atividade o item
correspondente no process standard e àqueles dos process patterns
que melhor se adeqüem. Para o process standard deve ser estabelecido
o auxílio de adaptação do standard e para os itens deve ser
102
estabelecido o auxílio de recomendação a respeito da aplicação do
item.
Após montar o guia do framework, repete-se se montando um guia
para cada atividade macro do framework. Para cada atividade macro
do framework, os componentes serão as atividades detalhadas e no
contexto inclui-se as situações do contexto e quando deve-se usar os
métodos/técnicas.
Entrada Framework, matriz de generalização de atividades completo,
características de cada atividade identificadas e atividades comuns
identificadas.
Saída Guia de reutilização do framework e guias de reutilização das
atividades macro
Responsável Engenheiro de processos
Atividade macro ADAPTAR O FRAMEWORK
Descrição Neste passo, procede-se da mesma forma que Pree, colocando-se em
prática o framework e fazendo-se as adaptações necessárias.
Entrada Framework, guias de reutilização.
Saída Framework adaptado
Responsável Engenheiro de processos
EXEMPLO DO GUIA DE REUTILIZAÇÃO
Para realizar a reutilização baseando-se no framework, pode-se fazer uso dos guias de
reutilização. Nos guias encontram-se os componentes (provenientes do usual process),
process standards e process patterns. Na coluna componentes do guia de reutilização
encontram-se dicas para o engenheiro de processos decidir se reutiliza determinado componente
ou não. As dicas foram definidas pelo engenheiro de domínio. Elas ditam se um componente, de
acordo com a análise de seu conteúdo (por exemplo, mais detalhado e claro) é mais indicado
indicado (+) para ser reutilizado ou não (-), ou se o componente possui a mesma informação da
atividade que está descrita no framework (=). Esta indicação é apenas uma dica e o engenheiro de
103
processos deve considerar outros aspectos durante a reutilização, como por exemplo se o
componente é adequado ao seu contexto. A seguir, apresenta-se o guia de reutilização
definido para o processo de engenharia de requisitos, o framework (Tabela 5) e um guia
de uma de suas atividades macro – Elicitar Requisitos (Tabela 6). A descrição detalhada
de como é realizada a reutilização, baseada nos guias, encontra-se no próximo capítulo.
GUIA DE REUTILIZAÇÃO
PROCESSO DE ENGENHARIA DE REQUISITOS
CONCEITO
( x ) Framework – Visão geral
do processo
( ) Atividade
[ ] Ponto Comum [ ] Ponto de Flexibilização
CONTEÚDO
Objetivo: Definir e gerenciar requisitos, através do entendimento do problema, da elicitação, da
análise, da modelagem e da validação dos requisitos e de uma negociação efetiva, com o objetivo
de obter um acordo dos requisitos a serem tratados no processo de desenvolvimento/ manutenção
de software.
Atividades
(atividades
macro do
framework)
Característica
(dicas sobre a
atividade no
domínio)
Componentes
(¨”+” - mais indicado, e “-“ – menos
indicado – de acordo com seu conteúdo,
“ =” conteúdo igual ao da atividade do
framework)
Process Standard /Pattern
Se o componente não for utilizado
mantém-se a descrição existente no
framework.
Process
Standard
CMM N2
( )Todo
Adaptação
Process
Standard
ISO/IEC 12207
( )Todo
Adaptação
Process
Pattern
Definir o
problema
OPcional,
ESpecífica
(=) Definir o Problema – Rational
(utiliza use case e aplica-se para
quando se desenvolver novos
sistemas)
(-) Definir Escopo – Alistair
(+) Estabelecer objetivos – Kotonya
104
Elicitar
Requisitos
COmum,
Essencial
(=) Elicitar requisitos – Kotonya
(+) Elicitar requisitos – Leite
(+) Elicitar requisitos – Loucopoulos
(-) Coletar fatos – Alistar
(-) Identificar requisitos – Alcazar
(+)Identificar Requisitos – Brackett
(-) Entender Necessidades dos
Stakeholders (possui Elicitar
requisições dos Stakeholders) –
utiliza use case – Rational
Processo de
desenvolviment
o – atividades
analisar
requisitos de
sistema e
software (ver
guia da ativ
Elicitar)
Construir
sistemas
certos –
Identificar
fontes de
requisitos,
Categorizar
fontes de
requisitos
(ver guia da
ativ. Elicitar)
Analisar
Requisitos
COmum ,
Essencial
(+) Analisar requisitos – Kotonya
(-) Analisar Requisitos – Julio (possui
uma atividade detalhada – validar –
que no framework é atividade macro)
(+) Analisar requisitos – Alcázar –
(análise em cima de um modelo de
domínio do problema)
(+) Análise de requisitos – Brackett
(-) Analisar requisitos – Alistair
Processo de
desenvolviment
o – atividades
analisar
requisitos de
sistema e
software (ver
guia da ativ.
Analisar)
Modelar
Requisitos
COmum,
Essencial
(=) Modelar Requisitos – Leite
(+) Modelar requisitos e domínio –
Alistar
(-)Especificar Requisitos (possui
Sintetizar conhecimento dentro de
um modelo de negocio) –
Loucopoulos
(+) Capturar a Especificação da
Solução – Alcázar (voltada para use
case)
(-) Documentar requisitos – Kotonya
(-) Representar Requisitos – Brackett
Processo de
desenvolviment
o – atividades
analisar
requisitos de
sistema e
software (ver
guia da ativ.
Modelar)
105
Negociar
Requisitos
OPcional,
REComendável
IMplícito,
FOra
(=) Negociar Requisitos – Kotonya
(+) Negociar requisitos comuns –
Alistar
(-) Comunicar Requisitos – Brackett
(+) Análise de prós e contras –
Alistair
Gerenciar
expectativas
do cliente,
Manter o
relacionamen
to com o
cliente
(ver guia da
ativ.
detalhada
Negociar)
Validar
Requisitos
COmum,
Essencial
(muitos não
tem atividade
detalhada, mas
só as técnicas)
(=) Validar requisitos – Loucopoulos
(-) Validar requisitos – Kotonya
(-) Validar requisitos – Alistair
Processo de
desenvolviment
o – atividades
analisar
requisitos de
software (ver
guia da ativ.
Validar)
Construir
protótipos,
Conduzir
reuniões de
revisão
(ver guia da
ativ. Validar)
Gerenciar
Requisitos
Opcional,
REComendável
FOra (a
atividade
rastrear
requisitos
muitas vezes
está fora deste
processo como
outra atividade)
(=) Gerenciar Mudanças de
Requisitos – Rational
(+) Gerenciar Requisitos – Kotonya
Rever
requisitos
alocados
Controlar
mudanças
nos
requisitos
alocados
(Ver guia
da ativ.
Gerenciar)
Analisar
requisitos de
software
(Ver guia da
ativ. Gerenciar)
Itens não abordados pelo framework:
CMM N2:
ü Medição: Determinar o estado das
atividades de gerência de requisitos ü Verificação: Revisar atividades de
gerência de requisitos (gerente sênior e
de projeto) e revisar e auditar as
atividades e artefatos de gerência de
requisitos (SQA) Recomendação 1
CONTEXTO
Ver as situações de contexto no guia das atividades macros.
Ver o elemento “características” do processo.
Tabela 5 – Exemplo de guia de reutilização do framework (processo)
106
Na coluna do process standard encontra-se um link para “Adaptação”. Exemplificando
parcialmente esta adaptação ter-se-ia, para o CMM N2:
“As atividades do process standard CMM N2 são voltadas para a Gerência de Requisitos, portanto
abrangem somente parte do framework – especificamente a atividade de gerência e validação de
requisitos”.
Atente-se que muitas características comuns do padrão CMM, como por exemplo, compromissos,
habilitações e por vezes atividades podem estar, por exemplo, como entradas, saídas, pré ou pós-
condições do process standard”.
GUIA DE REUTILIZAÇÃO
ELICITAR REQUISITOS
CONCEITO ( ) Framework – Visão geral do
processo
( x ) Atividade
[x] Ponto Comum [ ] Ponto de Flexibilização
CONTEÚDO
Objetivo: Identificar os fatos que compõem os requisitos do sistema, de forma a prover o mais correto
entendimento do que é demandado daquele software. Elicitar tem o objetivo de facilitar o entendimento sobre o
problema.
Atividades
(atividades
detalhadas do
framework)
Características
(dicas sobre a
atividade no
domínio)
Componentes
(¨”+” - mais indicado, e “-“ – menos indicado –
de acordo com seu conteúdo, “ =” conteúdo
igual ao da atividade do framework)
Process Standard/Pattern
Se o componente não for utilizado mantém-se
a descrição existente no framework CMM N2 ISO/IEC
12207
Process Pattern
Identificar fontes
de informação
OPcional,
REComendável,
IMplícito
(=)Identificar fontes de informação – Leite
(+) Identificar fontes de conhecimento de
requisitos – Loucopoulos
Construir sistemas
certos -
Identificar fontes de
requisitos
Coletar Fatos COmum ,
Essencial
(+) Coletar Fatos – Leite
(+) coletar requisitos dos stakeholders/ adquirir
o conhecimento do cenário – Kotonya e
(usadas em conjunto)
(+) Adquirir conhecimento – Loucopoulos
(+) Elicitar de pessoas/ derivar req. de SW de
sistemas/ analisar tarefas para desenv. req. de
interface) – Brackett (ainda não disponível)
(-) Elicitar requisições dos stakeholders (possui
coletar informações) – Rational – faz uso de
use cases
Analisar
requisitos
de sistema
Analisar
requisitos
de software
Recomend
ação I
107
Organizar
Conhecimento
OPcional,
ESpecífico, FOra,
IMplícito
Muitas vezes
está na atividade
de modelagem
(+) Organizar Conhecimento – Kotonya
(+) Decidir a relevância do conhecimento do
problema em questão (entender o significado
do conhecimento elicitado) – Loucopoulos e
(ainda não disponível)
Construir sistemas
certos -Categorizar
fontes de requisitos
CONTEXTO
Situações do contexto: Use o método/ técnica:
ü É preciso reduzir problemas de falta de consenso. Brainstorming – BDCA
ü É preciso um entendimento detalhado do sistema e do domínio da aplicação, e
se tem tempo para elicitar requisitos.
Etnografia
ü É preciso diminuir os custos e reutilizar conhecimento. Reutilização de conhecimento (requisitos)
ü Não se está certo de qual o tipo de sistema que realmente é necessário em um
contexto particular.
Metodologia de sistemas soft
ü É preciso detalhar requisitos e descobrir as possíveis interações do sistema e
possíveis “facilities”.
Cenários
ü Deseja-se aplicar a técnica similar a etnografia, mas em um tempo reduzido. Pesquisa contextual (contextual inquiry)
ü É preciso mostrar como os requisitos serão traduzidos dentro de um sistema;
definir interface.
Prototipação
ü Busca-se respostas para um conjunto pré-definido de perguntas. Entrevistas Fechadas
ü Deseja-se uma discussão aberta, sem agenda pré-definida. Entrevistas Abertas
ü Deseja elicitar requisitos e a fonte de informação são pessoas JAD, Entrevistas Abertas, Entrevistas
Fechadas (entre outros)
ü Se tem um bom conhecimento sobre o problema e se quer varrer um grande
número de pessoas.
Questionários
ü Quando se quer entender, capturar, o comportamento do sistema Use case (casos de uso)
ü Quando se deseja definir a linguagem da aplicação, descrever seus símbolos
(palavras ou frases que parecem ter um significado especial na aplicação).
LAL. – Léxico Ampliado da Linguagem
Guia: associe os métodos/ técnicas ao processo/ atividades após gravar a instância do framework. Apresentou-se algumas situações;
algumas técnicas podem ser utilizadas em conjunto, combinadas.
Tabela 6 – Exemplo do guia de reutilização da atividade macro
Na coluna do process standard encontra-se a “Recomendação I” – em Coletar fatos,
juntamente com os componentes que poderão ser reutilizados (analisar requisitos de
sistema e analisar requisitos de software). O conteúdo desta recomendação é:
• Primeiro consulte a descrição (dados) do componente e após veja a recomendação.
• O process standard indica o que deve ser coletado “a especificação dos requisitos
deve descrever ...” (embora sob a palavra de especificação). As partes referentes aos
itens 5.3.2.1 (análise de requisitos de sistema) ditam o que deve ser coletado.
108
Complemente com a parte da atividade da análise de requisitos de software - parte
5.3.4.1 da norma.
A seguir, descreve-se algumas dificuldades encontradas para montar o framework de
processos.
DIFICULDADES PARA MONTAR O FRAMEWORK DE PROCESSOS
As principais dificuldades encontradas para se desenvolver um framewok de processo de
engenharia de requisitos foram, provavelmente, muitas relacionadas com a maturidade
dos processos. Estas dificuldades foram:
• As descrições em si – alguns autores descrevem em um nível muito alto, dificultando a
comparação no nível das atividades detalhadas; algumas atividades, por exemplo,
modelar, não tinha descrição alguma senão a referência para técnicas;
• Nível das atividades – atividades que para alguns eram macros para outros eram
detalhadas;
• Escopo das atividades – atividades que para alguns estavam dentro de uma atividade x
para outros estavam em outra atividade y;
• Entendimento do domínio – começando pelo que se entende por engenharia de
requisitos – para alguns é o processo de definição, para outros é a análise e para
alguns é gerenciar requisitos. Para atividades o mesmo problema ocorria;
• Nomes das atividades – diferentes nomes para referir-se ao mesmo assunto e muitas
vezes o nome de uma atividade representando duas atividades;
• Atividades “recentes” – alguns processos mais atuais abordam atividades que os outros
processos não abordam, devido a maturidade, obtendo-se no final uma pontuação
baixa para esta atividade mais “recente”. Embora se saiba da sua importância ela não
atingia pontuação suficiente para ser um ponto comum e essencial no framework.
• Tempo – a construção do framework, como se tem conhecimento, é uma atividade que
toma muito tempo, visto que é manual, e requer muita análise.
A definição das características foi uma forma de “trabalhar” os problemas encontrados e
viabilizar a construção do framework.
109
RESUMO
Inicialmente, salientou-se que os frameworks para processos de engenharia de software
são mais genéricos e os frameworks onde os processos do domínio são maduros, podem
ser orientados à implementação. Realizou-se uma comparação entre o processo de
desenvolvimento de frameworks, segundo Pree [34] e a proposta definida para processos,
concluindo-se que elas diferem no objeto manipulado - processos, diferem no
detalhamento dos itens “definir modelo de objetos do domínio e identificar hot-spots”, e
diferem no projeto do framework, pois utilizamos as características e os guias de
reutilização (similares ao hot spot cards).
Descreveu-se o processo de definição de frameworks de processos que possui as
seguintes atividades: gerar modelo de processos, definir matriz de generalização das
atividades, definir pontos comuns, definir características, montar o framework, montar
guias de reutilização e adaptar o framework. O processo consiste em selecionar alguns
processos do domínio desejado, modelá-los na linguagem de um usual process e
posteriormente realizar a comparação de suas atividades, identificando os pontos comuns
e opcionais, bem como características destas atividades no domínio.
Para auxiliar na tarefa da análise, são montadas matrizes onde se escolhe um processo
base e compara-se, sua atividade macros com as outras, dos outros processos. Isto é
realizado para cada atividade do processo base e para outras atividades, dos outros
processos, que o processo base não abordou. As atividades recebem rótulos de acordo
com a igualdade de seus nomes, analisando-se as facetas, e de acordo com a análise do
engenheiro de domínio/ processos (por exemplo, verificando as atividades detalhadas).
Estes rótulos determinam uma pontuação que ajuda a definir se uma atividade é comum
no domínio ou não. Repete-se então o mesmo conjunto de passos para analisar as
atividades detalhadas. Definidas quais são as atividades comuns e opcionais, documenta-
se o framework, segundo a linguagem de um usual process e em seguida monta-se os
guias de reutilização baseando-se nas matrizes e no framework. Para finalizar deve-se
colocar em uso o framework para verificar as adaptações necessárias.
110
Os guias de reutilização definidas são diretrizes para auxiliarem o engenheiro de
processos na reutilização e instanciação dos processos. Indicam as características das
atividades, definindo àquelas comuns e opcionais (hot-spots), mostram componentes e,
process patterns que podem preencher atividades opcionais do framework. Fornece links
para process standards para o engenheiro de processos verificar se as descrições
existentes atendem aos standards ou não ou mesmo para reutilizá-los.
Um processo de engenharia de requisitos exemplificou o que seria o resultado dos passos
da elaboração de um framework de processos/guia de reutilização. As principais
dificuldades na elaboração do framework do processo de engenharia de requisitos foram
descritas, sendo muito delas relacionadas a maturidade dos processos do domínio em
questão.
111
Capítulo 6 – Reutilização de Processos
Este capítulo descreve como os processos são reutilizados e instanciados e como é gerada a
instância de um processo, a partir de um framework ou não. O processo de reutilização é
descrito utilizando-se a linguagem de um usual process, entretanto mostra-se apenas o item
essencial para o entendimento do processo. Finalizando, introduz-se alguma das funcionalidades
da ferramenta (protótipo) de apoio ao processo descrito.
REUTILIZAÇÃO DO FRAMEWORK X ESCOLHA LIVRE DE COMPONENTES
Como mencionado, pode-se reutilizar processos a partir de um framework ou não (Figura
23). Reutilizando-se a partir de um framework tem-se um processo genérico e a indicação
dos componentes (atividades) que podem ser utilizados para complementar os pontos
comuns e/ ou preencher os pontos de flexibilização (hots pots). Reutilizando sem o
framework (escolha livre de processos/ componentes) o engenheiro de processos tem que
encontrar os processos e componentes desejados para definir a instância do processo.
Para ajudá-lo, neste tipo de reutilização, conta-se com diversos recursos de pesquisa.
Desta forma, o engenheiro de processos “navega” entre as bases dos diferentes tipos de
processos escolhendo os componentes desejados. No caso do usual process ele pode
reutilizar todo o processo, pois como descrito possuem a mesma linguagem.
Instânciade processo
Reutilizar o framework
Reutilizar processoslivremente
ReutilizaçãoTotal
ReutilizaçãoParcial
USUAL Proc
Proc STANDARD
Proc PATTERN
USUAL Proc
- Diversos recursos depesquisa- busca e decisão de quais componentes reutilizar
USUAL Proc Proc STANDARDProc PATTERN
USUAL Proc
- processo semi-acabado- guias de reutilização(indicaçãode componentes a reutilizare características)
(hotspots)
Figura 23 – Reutilização de processos
112
Reutilizando-se de forma livre obtém-se:
• usual processes que já foram definidos por organizações ou pesquisadores, podendo-se
localizar processos com características semelhantes ao da organização que deseja
definir um processo, sendo que alguns deles podem estar em conformidade com
modelos ou normas;
• process standards que mostram normas e modelos na forma de processo, auxiliando no
entendimento do standard e traçando um caminho para a definição dos processos que
se queira que estejam em conformidade com determinadas normas e modelos;
• process patterns que divulgam soluções testadas de problemas recorrentes e podem ser
a base da definição de um processo ou podem ser o próprio processo que se esteja
buscando.
Reutilizando-se a partir de um framework obtém-se:
• um processo genérico que foi estabelecido analisando-se vários outros processos do
domínio, e extraindo-se, da maioria deles, suas partes comuns e suas características
específicas. Traduz, de certa forma, a maturidade das pesquisas e práticas correntes
naquele domínio;
• um usual process que possui associado a ele guias de reutilização, mostrando
características das atividades (macro e detalhada) no referido domínio e indicando
componentes que podem ser utilizados para complementar atividades ou preencher
pontos de flexibilidade do framework;
• um processo que possui links de suas atividades com itens de process standards e
componentes de patterns disponíveis na base de dados, dispensando trabalhos de
busca, identificação e correlação.
Cabe lembrar que o fato de reutilizar process standards não garante que a organização
esteja em conformidade com a norma/ modelo, pois a certificação da organização não
depende apenas da descrição de um processo, mas entre outros, da institucionalização das
práticas descritas no processo e de sua cultura. O process standard é um guia, ele
organiza o standard de tal maneira que se pode organizar a instância de processo da
mesma forma, ganhando-se em tempo de entendimento e definição. Os auxílios
113
“adaptação” e “recomendação” associados ao standard também proporcionam os mesmos
ganhos. No entanto, o engenheiro de processos ainda tem que fazer a definição de como o
processo vai acontecer na sua organização, pois o standard possui uma descrição em um
nível muito alto de abstração. Manter a estrutura de processo fornecida pelo process
standard, ou pelo menos seus itens, irá auxiliá-lo em não deixar de definir algo
necessário para que atinja a conformidade com o standard. Salienta-se também que o
standard original não deve ser dispensado, precisa ser conhecido e é base para a definição
de processos.
No framework procura-se utilizar standards de uma forma diferente da usual.
Usualmente, escolhe-se o standard e a partir dele definem-se atividades do processo. Para
agir desta forma usual, pode-se ir até a base de process standard, independente do uso do
framework, e escolher um process standard, obtendo-se as atividades default do
standard. Estas atividades podem ser escolhidas e passadas para uma instância de
processo onde a descrição pode ser complementada, segundo cultura e contexto da
organização.
No framework, usando seu guia de reutilização, parte-se de um processo genérico e para
suas atividades, que podem ter um ou mais itens do standard associado, se verifica se a
descrição existente nelas atende ao standard e as necessidades da organização.
Obviamente, alguns itens dos standards não estão totalmente cobertos no framework,
sendo desta forma necessário defini-los. Auxílios do tipo “adaptação” do standard e
“recomendação” associados aos itens do standard ajudam na definição do processo.
O PROCESSO DE REUTILIZAÇÃO DE PROCESSOS
A seguir, descreve-se o processo de reutilização de processos utilizando-se parcialmente
a linguagem de um usual process. Este processo, visando a experimentação prática de um
estudo de caso, é apoiado por um protótipo de uma ferramenta (Reutilização de Processos
de Software On Line - RPS) que é ilustrada na próxima seção deste capítulo.
114
PROCESSO DE REUTILIZAÇÃO DE PROCESSOS
Autor Soeli Fiorini/ Julio C.S.P. Leite
Objetivo Gerar uma instância de processo (usual process) através da pesquisa e
reutilização de componentes (atividades) de bases de dados de tipos de
processos (usual, standard e pattern) ou a partir de um framework de
processos.
Descrição Considerando-se que o usuário (engenheiro de processos) já tem em
mente uma idéia do que ele deseja reutilizar, ele pode então escolher
em reutilizar processos a partir de um framework ou não (pesquisa
livre). Inicialmente, para ambos os casos deve-se criar um processo
novo, do tipo usual process, para conter a instância de processo.
Reutilizar livremente significa que devem-se selecionar a base de
processos desejada e pesquisar pelo processo/ componentes que
atendam as necessidades. Uma vez encontrado os processo/
componentes desejados, eles podem ser totalmente ou parcialmente
reutilizados e armazenados na instância de processo. Os diferentes
tipos de processos (usual, standard e pattern) possuem um núcleo em
comum (atividades, itens e componentes, respectivamente). Sendo
assim a instância do processo pode ser composta de componentes que
foram reutilizados dos três tipos de processos. Por exemplo, uma
instância que contém atividades de um usual process pode ser
complementada com itens de process standards ou componentes de
um pattern. Itens, dos standards, e componentes, dos patterns, têm o
sentido de uma atividade em usual process e vice-versa. Operações do
tipo “copiar e colar” dados podem ser realizadas livremente dos
processos da base para a instância.
Reutilizar utilizando um framework significa que existe um processo
genérico, do tipo usual process, que já possui atividades definidas e
que conta com guias de reutilização indicando, através de
características, quais são as atividades comuns essenciais e àquelas
opcionais. Também indicam, através de links para as bases de
115
processos, quais são os process patterns/componentes e quais são os
process standards/itens associados com cada atividade do framework.
Componentes, no guia de reutilização, referem-se a outras atividades
de outros processos similares que podem auxiliar na complementação
das descrições das atividades comuns do framework ou que podem
preencher os seus pontos de flexibilização.
Após a reutilização, complementações podem ser realizadas nas
descrições reutilizadas e pode-se visualizar a instância de processo em
um browser na forma textual seqüencial, bem como salvar o processo
no formato XML.
Representação macro
Reutilizar processos livremente
Reutilizar o
framework
Base dedadosdeprocessos
Instância doprocesso (usualprocess)
Complementarprocesso(instância)
Incluirnovo
processo (instância)
Instância doprocesso comple-mentada
Representação
detalhada
Fim
Realizar a pesquisa p/reutilização
Selecionarprocesso
destino -parcial
Selecionar oframework de
processo
Escolher o
standard
Selecionaratividades
macro
Escolher atividadesdetalhadas
Complementarprocesso
(instância)
Início
Definir usando framework?
Instância de
processo
Reutilizar Livremente - Parcial
Incluirnovo processo
(instância)
Reutilizarcomponentes
processos&<
& <
Reutilizar todoprocesso?
N
Selecionarprocesso
- total
Selecionarprocesso
destino - total
Reutilizardados de processo& <
Selecionar o processodestino
Reutilizar Processo - Total
SN
S
Reutilizar Framework & <
& <
Função Resp. Engenheiro de processos
Entrada Base de dados de processos
Saída Instância de processo
Ferramenta Reutilização de Processos de Software On line (RPS)
116
Atividade macro INCLUIR NOVO PROCESSO (INSTÂNCIA)
Descrição No item “cadastro usual process/ usual process/ incluir”, da
ferramenta, fornecer os dados iniciais (nome e natureza) do usual
process a ser criado como base para armazenamento da instância de
processo. A natureza do processo deve ser “projeto”. Gravar e voltar
para o menu principal para realizar a pesquisa. Uma vez criada a
instância, ela pode ser utilizada para armazenar dados reutilizados de
qualquer tipo de processo.
Entrada Dados iniciais do processo
Saída Instância de processo
Responsável Engenheiro de processos
Atividade macro REUTILIZAR PROCESSOS LIVREMENTE (PARCIAL/ TOTAL)
Descrição Após criar o processo que irá conter a instância de processo, deve-se
questionar se estará utilizando um framework ou não. Caso não se
utilize um framework deve ser realizada a pergunta se a reutilização
será parcial ou total. Na parcial, pode-se reutilizar componentes
(atividades) dos três tipos de processos, ou seja, o engenheiro de
processo deve navegar nas bases de dados de cada tipo de processo em
busca de atividades para compor o seu processo. É um trabalho de
pesquisa. Na total, reutiliza-se um processo do tipo usual process –
todos os seus dados – visto que ele está na mesma linguagem que a
instância do processo. No caso da reutilização total o engenheiro de
processos verifica o processo desejado (de uma lista indicada) e o
reutiliza. Definida se a reutilização será total ou parcial, parte-se então
para a pesquisa para encontrar os processos e componentes desejados.
Na reutilização parcial uma série de recursos para pesquisa é provida e
na total, uma lista de processos é fornecida e os dados deles podem ser
consultados. Depois de realizar a pesquisa, e se necessário comparado
os processos, pode-se realizar a reutilização. Entretanto, um processo
destino, ou seja, uma instância de processo, que irá conter os dados
117
reutilizados deve ser selecionada. Uma vez o processo/ componentes
foram escolhidos e reutilizados, se necessário, sua descrição pode ser
complementada, segundo cultura e contexto da organização.
Entrada Base de dados de processos
Saída Instância de processo
Restrição No caso de process standard, quando se deseja conformidade, as
atividades reutilizadas devem ser adaptadas.
Responsável Engenheiro de processos
Atividade detalhada
REALIZAR A PESQUISA PARA REUTILIZAÇÃO – PARCIAL
Descrição Com a finalidade de conhecer os processos deve-se selecionar a base
de dados desejada (usual process, process standard ou process
patterns). A pesquisa pode consistir em escolher um conjunto de itens
em uma combo box – para alguns elementos do processo (por exemplo
classificação, autor, ...), ou digitar palavras-chave, ou utilizar facetas
e/ou atributos do processo para facilitar a busca. Também pode ser
mais estruturada, seguindo a estrutura dos tipos de processos,
selecionando itens em combo box (pesquisa estruturada). O retorno da
pesquisa é um resultado com zero ou n processos (lista de processos)
que poderão ser comparados (nome das suas atividades), com base nas
facetas. Na comparação (aplicada somente a usual process) são
indicadas, para cada atividade de um processo escolhido, como base
para a comparação, as ações iguais ([A]), objetos iguais ([O]) e
sinônimos ([S]) – em relação aos outros processos. Novas pesquisas
podem ser realizadas até que se encontre os processos/ componentes
desejados.
Entrada Dados para a pesquisa
Saída Resultado da pesquisa (lista de processos)
Responsável Engenheiro de processos
118
Atividade detalhada SELECIONAR O PROCESSO DESTINO (INSTÂNCIA DE
PROCESSO) - PARCIAL
Descrição A finalidade é selecionar o processo criado anteriormente para conter
a instância do processo. No mesmo local da pesquisa, seleciona-se o
processo destino criado para conter a instância. Os dados do processo
e suas atividades podem ser visualizados clicando no ponto de
interrogação ao seu lado, caso já tenham anteriormente recebido
alguma atividade reutilizada.
Entrada Lista de usual process
Saída Instância de processo selecionada
Responsável Engenheiro de processos
Atividade detalhada REUTILIZAR COMPONENTES DE PROCESSOS - PARCIAL
Descrição Buscando reaproveitar descrições de outros processos para criar um
novo, realiza-se a reutilização utilizando o resultado da pesquisa (lista
de processos e seus componentes), anteriormente realizada. Para a
reutilização parcial, a lado de cada componente (atividade/ item/
componente – de acordo com cada tipo de processo) existe uma seta
(<) que quando pressionada insere-o na instância do processo.
Diferentes componentes podem ser reutilizados de diferentes
processos. No processo destino existe botões com setas para
movimentação da atividade para cima (/\) e para baixo (\/) –
determinando sua provável ordem – e um botão com um “x” (X) para
realizar a sua exclusão.
Para trocar de base de dados e continuar a reutilização com outros
tipos de processos, deve-se gravar a reutilização realizada e voltar para
a página principal e iniciar novamente a pesquisa (item “reutilizar
livremente – parcial ...”) e selecionar a nova base de dados, pesquisar
e abrir novamente o processo destino que se estava construindo na
pesquisa anterior. As novas atividades/ itens/ componentes serão
adicionadas à instância existente.
Entrada Resultado da pesquisa
119
Saída Instância de processo
Responsável Engenheiro de processos
Atividade detalhada SELECIONAR PROCESSO – TOTAL
Descrição Caso deseje-se reutilizar todos os dados de um processo, do tipo usual
process, deve-se escolher – de uma lista de processos em uma combo
box – àquele desejado. Ao lado de cada processo selecionado tem-se o
recurso de consulta para verificar os seus dados. Pode-se selecionar e
consultar quantos processos desejados.
Entrada Lista de processos
Saída Processo selecionado
Responsável Engenheiro de processos
SELECIONAR O PROCESSO DESTINO (INSTÂNCIA DE
PROCESSO) – TOTAL
Descrição Escolhido o processo deve-se selecionar o processo destino (instância
do processo) criado para conter o processo a ser reutilizado. O
processo destino escolhido não deve conter dados (além do nome e
natureza), pois senão serão sobrepostos com os dados do processo
escolhido.
Entrada Lista de usual process
Saída Processo destino
Responsável Engenheiro de processos
REUTILIZAR PROCESSO - TOTAL
Descrição Uma vez que o processo a ser reutilizado e o processo destino estão
selecionados, deve-se então realizar a reutilização. Para tanto, existe
um botão “reutilizar”, na ferramenta, que ao ser pressionado
automaticamente cria a “cópia” do processo escolhido para o processo
destino. Todos os dados, de todos os elementos do processo serão
reutilizados (atividades, formulários, política, ....).
Entrada Processo destino e processo selecionado para reutilização
120
Saída Instância de processo
Responsável Engenheiro de processos
Atividade Macro REUTILIZAR O FRAMEWORK
Descrição Com o objetivo de realizar a definição de um processo a partir da
reutilização de descrições de um framework (processo genérico),
deve-se selecionar o framework desejado13 e o processo destino que
irá conter a instância de processo a ser gerada. Selecionando-se o
framework, suas atividades e o seu guia de reutilização são mostrados.
Com base no guia deve-se escolher um standard, quando se desejar
conformidade. Após, seleciona-se as atividades macro, com base em
suas características (o guia indica as atividades opcionais) e para as
atividades que serão mantidas e que são opcionais, pode-se selecionar
um componente proveniente de um usual process ou de um process
pattern ou de um process standard. O próximo passo é verificar nas
atividades detalhadas, àquelas que serão mantidas. Para as opcionais
pode-se também definir o componente. Para isto, o guia de
reutilização de cada atividade macro está disponível, mostrando os
componentes que podem preencher as atividades detalhadas.
Selecionadas as atividades, a instância de processo deve ser gravada.
Após complementações/ adaptações nas descrições da instância de
processo podem ser realizadas, quando necessário.
Entrada Framework e guias de reutilização
Saída Instância de processo
Responsável Engenheiro de processos
13 A ferramenta, atualmente, apresenta um único framework – o do Processo de Engenharia de Requisitos.
121
Atividade detalhada SELECIONAR O FRAMEWORK DE PROCESSO
Descrição Escolher, na ferramenta a opção “Reutilizar framework” e selecionar
um framework da lista de frameworks existentes. Eles estão
armazenados como um usual process. Os dados do framework podem
ser consultados utilizando o botão [?] ao lado do nome do framework
selecionado.
Entrada Lista de frameworks
Saída Framework e guias de reutilização
Responsável Engenheiro de processos
Atividade detalhada SELECIONAR O PROCESSO DESTINO
Descrição Deve-se selecionar o processo destino (instância do processo) criado
para conter o processo a ser reutilizado. O processo destino escolhido
não deve conter dados (além do nome e natureza), pois senão serão
sobrepostos com os dados do processo escolhido, pois ao selecionar o
processo destino e a opção “Reutilizar”, automaticamente os dados do
framework serão passados para esta instância. Assim a instância herda
do framework as atividades macros comuns [CO] e essenciais [E] com
suas atividades detalhadas as atividades opcionais [OP] com uma
descrição default. Sendo assim, o engenheiro de processos vai estar
“construindo” seu processo, em cima da instância, preenchendo
pontos de flexibilização (atividades opcionais) com componentes,
rescrevendo-as ou as excluindo do processo.
Entrada Lista de usual process
Saída Instância do framework
Responsável Engenheiro de processos
122
Atividade detalhada ESCOLHER O STANDARD
Descrição Nos guias de reutilização verificam-se quais os standards para os
quais o framework tem mapeamento. Pergunta-se então, se o processo
a ser gerado deve estar em conformidade com todo um standard ou se
deseja apenas abordar alguns itens do standard ou mesmo não abordá-
los. No guia, cada atividade do framework pode ter referências a itens
de um standard “x”. Se a opção escolhida for ter referências, o
engenheiro de processos deve considerar que eventuais atividades
opcionais podem ter itens de standards associados não devendo desta
forma ser apagadas. Também ao reutilizar componentes deve-se
verificar o componente que melhor atende ao item do standard. Ele
também pode reutilizar o próprio item do process standard e pode
posteriormente defini-lo. Se a opção for estar em conformidade com
todo o standard (todo neste caso pode representar um nível – por
exemplo, no CMM), ele seleciona no guia de reutilização a opção
“todo”, na coluna standard. Isto é necessário, pois alguns itens do
standard não encontram referências nas atividades, sendo então,
quando do desejo ou da escolha da opção “todo”, necessário serem
incluídos na instância do processo sendo gerado.
Os auxílios de “recomendação” e “adaptação” associados aos itens do
process standard devem ser utilizados pelo engenheiro de processos
para verificar qual é o melhor componente a ser reutilizado ou o que
ele deve complementar nas atividades já existentes no framework. A
adaptação é o conhecimento de um especialista sobre o standard e
visa apenas facilitar o seu entendimento, diminuindo dúvidas de como
usar o process standard com relação ao framework. A recomendação
é uma dica de como o item pode ser aplicado na atividade. Na
verdade, estes dois auxílios devem ser utilizados sempre que
atividades macro ou detalhada forem escolhidas e definidas ao longo
do processo de reutilização.
Entrada Guias de reutilização
Saída Escolha de um standard – todo, alguns ou nenhum de seus itens.
123
Responsável Engenheiro de processos
Atividade detalhada SELECIONAR ATIVIDADES MACRO
Descrição Selecionar as atividades macros significa verificar aquelas atividades
provenientes do framework que devem ser mantidas ou não na
instância e preencher os pontos de flexibilização do framework (hots
spots). No guia de reutilização do framework encontram-se as
características de cada atividade macro, como por exemplo,
[OP]cional e [ES]sencial, para auxiliar na escolha. Cada atividade
macro comum quando inserida no novo processo (instância do
framework) herda os dados do framework. As atividades macro
opcionais ficam com dados default aguardando, se mantidas na
instância, que sejam, se necessário, substituídas por componentes ou
sejam redefinidas. Quando as atividades opcionais não forem mantidas
deve ser explicitado, marcando-se a opção “não reutilizar”, ao lado da
atividade. Os possíveis componentes para cada atividade do
framework são provenientes da base de dados dos tipos de processos.
Os componentes podem ser consultados e as atividades opcionais
também podem ser substituídas por process patterns/ componentes ou
process standards/ itens – o guia de reutilização também faz esta
referência. A reutilização dos componentes é realizada selecionando-
se ao lado de cada atividade, em uma combo box, os componentes
provenientes do usual process, process patterns ou process standard.
Somente um componente pode ser escolhido. Os componentes
provenientes de process patterns e process standard tem elementos do
seu núcleo e o equivalente a atividade macro reutilizado.
Componentes provenientes de um usual processo tem todos os
elementos da atividade reutilizados.
Entrada Guia de reutilização da atividade macro, componentes da base usual
process, process pattern e process standard, instância do framework
Saída Atividades macros selecionadas
Responsável Engenheiro de processos
124
Atividade detalhada ESCOLHER ATIVIDADES DETALHADAS
Descrição Uma vez que as atividades macros foram escolhidas e preenchidas (se
necessário), para cada atividade detalhada comum deve-se verificar as
atividades opcionais. Procede-se da mesma forma que na atividade
macro, neste caso utilizando-se os guias de reutilização de cada
atividade macro (mostrados ao pressionar o botão “guia” ao lado de
cada atividade). No guia de reutilização da atividade, na parte
contexto, encontram-se também métodos/ técnicas com a indicação de
quando devem ser utilizados no processo. Elas deverão ser
acrescentadas na complementação das atividades.
Entrada Guia de reutilização da atividade macro, componentes da base usual
process, process pattern e process standard, instância do framework
Saída Instância do processo
Responsável Engenheiro de processos
Atividade Macro COMPLEMENTAR INSTÂNCIA DO PROCESSO
Descrição Nesta atividade procura-se complementar (alteração, inclusão)/
adaptar as descrições da instância do processo às características da
organização. Uma vez que a instância de processo foi “montada”
pode-se, quando necessário complementar e/ou alterar as descrições
reutilizadas e deve-se preencher os campos que estão em branco (que
não existiam no tipo process standard e process pattern) – quando a
reutilização não foi baseada em um framework ou usual process.
Novas atividades podem ser definidas.
Para realizar a complementação deve-se entrar no modo “Cadastro
usual process/ usual process”, selecionar a instância gerada e editá-la.
Após as complementações, o processo pode ser visualizado no
browser selecionando, na ferramenta, a opção “Consultas/ exportar
processo em XML”. Pode-se visualizá-lo na forma textual e
sequencial, ou na forma XML – mostrando-se o arquivo fonte XML.
O arquivo fonte XML do processo pode ser salvo na área de trabalho
do engenheiro de processos, selecionando-se no menu do browser a
opção “Arquivo/salvar como”.
125
Entrada Instância do processo
Saída Instância do processo complementada
Restrição No caso de se querer estar em conformidade com um standard, as
atividades reutilizadas devem ser a base para realizar a definição do
processo, juntamente com o standard.
Responsável Engenheiro de processos
A seguir, ilustramos as funcionalidades da ferramenta, relacionadas com as atividades
mencionadas no processo apresentado.
A FERRAMENTA
Um protótipo da ferramenta – Reutilização de Processos de Software On line (RPS) – foi
desenvolvido para dar apoio a reutilização de processos, mais especificamente para poder
realizar estudos de casos via WEB. O protótipo foi desenvolvido em ASP, com banco de
dados Access e está disponível na WEB (www.er.les.inf.puc-rio.br/soeli). A seguir,
descrevemos algumas de suas funcionalidades, através da ilustração de algumas de suas
telas.
6.1.1 CADASTRO
Na tela inicial (Figura 24) têm-se opções para se cadastrar os processos do tipo usual,
standard e pattern, cada um na sua linguagem, e realizar a reutilização. Também têm-se
as tabelas auxiliares que se referem a elementos do processo (por exemplo política,
conceitos, artefatos, verificações, ...). Acessando-as, encontra-se uma lista onde se pode
selecionar os elementos para a edição ou exclusão ou pode-se realizar a inclusão (Figura
25). As tabelas de conceitos, funções e artefatos são comuns aos três tipos de processos.
126
Figura 24 – Pagina Principal
Ainda na Figura 24 se visualiza o processo de reutilização com ligações (links) que
conduzem o engenheiro de processos às atividades de reutilização. A primeira atividade
do processo é “incluir novo processo” para que ele crie a instância do processo. Na
Figura 26, mostra duas telas uma visualiza-se a inclusão de um novo processo de natureza
igual a projeto. A outra tela mostra um processo com seus dados já cadastrados.
Selecionado-se cada atividade (double click) o seu conteúdo é visualizado e as setas
movimentam as atividades dentro do processo, definindo sua provável ordem. No canto
direito superior encontram-se links para os outros elementos do processo.
127
Figura 25 - Cadastro elementos do processo (tabelas auxiliares)
Figura 26 – Cadastro do usual process
128
6.1.2 PESQUISA
A Figura 27 mostra as opções de busca nas bases de dados dos tipos de processos. Neste
exemplo, usual process, a busca vai se dar pelas facetas (ação e objeto). Pode-se realizar
a combinação de vários itens para a pesquisa. Vários outros elementos constam desta tela,
como, por exemplo, características (não aparecem nesta Figura). Na Figura 28, visualiza-
se a pesquisa do process pattern que vai se dar, no exemplo, pela classificação da
comunidade e do problema das famílias e indivíduos. Tanto o process pattern quanto o
process standard possuem pesquisa através de vários elementos (Figura 28 e 29) e uma
pesquisa mais orientada pela estrutura de cada um deles (Figura 30).
Figura 27 – Pesquisa para usual process
129
Figura 28 – Pesquisa para process pattern
Figura 29 – Pesquisa do process standard
130
Figura 30 – Pesquisa do process pattern – realizada de forma mais estruturada
Na figura 30 verifica-se o botão com o sinal de “?”, quando pressionado, mostra o
conteúdo do processo. Guias básicos orientam a operação de pesquisa. Na pesquisa
estruturada, na medida que vai se realizando a escolha os dados vão sendo restringidos e
mostrados, até se chegar ao nível do equivalente a uma “atividade detalhada”.
A Figura 31 mostra, para um usual process, o resultado de uma pesquisa e a visualização
dos processos com suas respectivas atividades. No lado direito existe um link para a
representação do processo. Guias da operação de reutilização estão disponíveis (“Guias”).
Os detalhes do lado esquerdo desta figura estão descritos no próximo item (reutilização).
131
Figura 31 - Resultado da pesquisa, visualização do processo com suas atividades e
reutilização das atividades
Figura 32 – Comparação de atividades de processo
132
A Figura 32 ilustra a comparação entre os processos, no caso de usual processes,
podendo ser realizada no nível de atividades macro e detalhada. Mostra-se também que
deve ser escolhido o processo base para a comparação (qualquer um dentre os processos
do conjunto resultante da pesquisa). Pode-se observar os símbolos [A] de ação e [O] de
objeto para os nomes das atividades, representando as facetas e indicando quando existe
igualdade entre elas (do processo base – primeiro à esquerda - com os outros). O símbolo
[S] significa que a ação ou objeto de uma atividade é sinônimo de uma ação ou objeto
atividade do processo base da comparação. Isto é similar, com limitações ao processo de
comparação descrito no Capítulo 5, quando do desenvolvimento de frameworks.
Figura 33 – Reutilização usual process – total
6.1.3 REUTILIZAÇÃO
A Figura 31 ilustra a reutilização livre, onde se podem escolher as “atividades” de
qualquer processo resultante da pesquisa. Na Figura (lado esquerdo) observa-se a combo
box para selecionar o processo destino, instância criada para manter os dados reutilizados.
Também são visualizados os botões [?] e [<] ao lado de cada atividade do processo.
133
Quando o botão [<] for pressionado passa-se a atividade para a instância do processo
(lado esquerdo) levando consigo suas informações. Quando o botão [?] for pressionado se
tem acesso aos dados do processo. As atividades, após serem passadas para a instância,
podem ser excluídas [“x”] ou movimentadas para cima ou para baixo.
A Figura 33 ilustra a reutilização total de um usual process, onde se informa o processo
origem e o processo destino. O botão [?] mostra os dados.
Figura 34 – Escolha do framework e visualização de suas atividade para consulta
A Figura 34 mostra que se pode escolher o framework de uma lista e pode-se consultar
seus dados pressionando o botão [?]. Quando escolhido o framework desejado, deve-se
escolher o processo destino (instância) e então pressionar o botão “reutilizar”, que
conduzirá para a tela apresentada na Figura 35.
134
Figura 35 – Reutilização utilizando um framework
A Figura 35 mostra as atividades framework, à esquerda, e os componentes que podem
ser reutilizados (combo box) à direita. Na parte inferior da tela encontra-se o guia de
reutilização. De acordo com a atividade que está sendo reutilizada pode-se pressionar o
botão “Guia”, ao seu lado, para mostrar o guia de reutilização. Movimentando-se as telas,
através do scroll bar, pode-se deixar a atividade do guia e atividade do framework em
paralelo, facilitando a leitura do guia para fazer a instanciação. Dados das atividades
podem ser consultados, tanto os do framework quanto os do componente, e a opção “não
reutilizar” pode ser marcada. A Figura 36 mostra uma consulta.
135
Figura 36 – Consulta aos dados da atividade macro do framework/ componente
6.1.4 VISUALIZAÇÃO DO PROCESSO EM XML/XSL
Sempre que necessário, o engenheiro de processos pode visualizar no browser (Internet
Explorer) a instância do processo, na forma textual ou na forma de um arquivo fonte
XML (Figura 37). Na visualização textual não se tem links, tendo-se a informação de
forma sequencial (plana). Se necessário o engenheiro de processos pode salvar o arquivo
XML, da referida instância, na sua área de trabalho, podendo abri-lo em outras
ferramentas que trabalham com XML, como por exemplo, Microsoft XML Notepad.
Desta forma o usuário fica independente da ferramenta de reutilização, reutilizando
informação e estrutura do processo e utilizando-as, como por exemplo, em treinamentos
na sua organização.
136
Figura 37 – Visualização da instância do processo em XML/XSL
RESUMO
Este capítulo descreveu o processo de reutilização de processos, na linguagem de um
usual process, e ilustrou-o com algumas telas da ferramenta utilizada para realizar
estudos de caso deste trabalho.
Descreveu-se que os processos podem ser reutilizados a partir de um framework ou não.
Reutilizar sem fazer o uso de um framework significa que se deve selecionar a base de
processos desejada (usual, standard e pattern) e pesquisar, de forma estruturada ou não,
pelo(s) processo(s) que atenda(m) as necessidades. Os processos, totalmente ou
parcialmente reutilizados, são armazenados em uma instância de processo criada como
um usual process. Os diferentes tipos de processos (usual, standard e pattern) possuem
um núcleo em comum que é a informação que permite que uma instância de processo
possa conter partes (componentes) provenientes de qualquer um dos tipos de processos.
Reutilizar utilizando um framework significa que existe um processo genérico que já
possui atividades definidas e que conta com guias de reutilização indicando, através de
características, entre outras, quais são as atividades essenciais e opcionais que podem ser
137
reutilizadas. Também indicam quais são os componentes (atividades), quais são os
process patterns e quais são os itens de process standards associados com cada atividade
do framework e que podem preencher pontos de flexibilização.
Após a reutilização, complementações podem ser realizadas na instância do processo e a
mesma pode ser visualizada em um browser na forma textual sequencial. Também pode
ser salva como um arquivo XML na área de trabalho do engenheiro de processos,
reutilizando conteúdo e estrutura do processo e ficando independente da ferramenta.
138
Capítulo 7 Estudo de Caso
Este capítulo descreve um estudo de caso com uma empresa e um experimento realizados para
validar a proposta apresentada. Eles foram realizados com o auxílio da ferramenta apresentada
no capítulo anterior e que implementa a arquitetura para a reutilização de processos e, com a
experimentação via WEB. O resultado do estudo de caso encontra-se no Anexo D.
O ESTUDO DE CASO VIA WEB
O estudo de caso realizado procedeu-se com a disponibilização do protótipo da
ferramenta – Sistema de Reutilização de Processos On Line – na WEB para a “Empresa
Y” e da escolha de um projeto que estava iniciando. Nesta seção apresenta-se as
atividades a serem realizadas pela empresa, a descricão sumária do projeto, o modelo de
relacionamento estabelecido com o Cliente e como foi realizada a reutilização dos
processos.
7.1.1 ATIVIDADES
As atividades a serem realizadas no estudo de caso foram assim definidas:
ü Responder um questionário inicial para a coleta de dados da organização na qual o
respondente participa e para a coleta de dados sobre a experiência do respondente
com relação ao tópico processo de software. Este questionário respondido encontra-se
no Anexo B.
ü Definir um processo que seja utilizado em um projeto da empresa, com base nos
dados disponibilizados no banco de dados da ferramenta. O processo pode ser
definido seguindo a reutilização livre, “navegando-se” pelas bases de dados e
escolhendo-se os componentes para montar a instância de processo e/ou através do
framework. De preferência tentar utilizar os três tipos de processos (process pattern,
process standard e usual process).
ü Garantir que o processo definido tenha no mínimo três atividades macros e contenha
todos os elementos (funções, entradas, saídas...) obrigatórios.
ü Registrar o tempo gasto para realizar a reutilização.
139
ü Responder um questionário final com dados a respeito do uso dos diferentes tipos de
processos para realizar a reutilização. Este questionário respondido encontra-se no
Anexo C.
7.1.2 DESCRIÇÃO SUMÁRIA DO PROJETO
O projeto será o desenvolvimento de um grande sistema, estimativa de um ano, para
realizar a gestão de venda, distribuição, assinaturas e marketing de um jornal.
Módulo de Venda Avulsa
Deve cobrir toda a parte de venda de produtos da empresa (jornais) possibilitando por
exemplo, cobrança direta de Bancas; permitir uso de preços regionalizados,
possibilitando definição de percentuais de descontos à nível de Distribuidor aplicados ao
preço de capa praticado nestas ou definição direta do preço a praticar; suportar processo
de jornaleiros, possibilitando administrar tanto o jornaleiro como o Ponto de Venda deste
ou somente jornaleiros (interior);
Módulo de Distribuição
Deve por exemplo, suportar o processo de entrega de todo e qualquer produto ou partes
de um produto, sejam estes comercializados ou não pela empresa; e deve suportar e
controlar pontos de entrega bem como destinatários não advindos dos módulos de Venda
Avulsa e Assinaturas.
Módulo de Assinaturas
Deve por exemplo, suportar os processos de cobrança e entrega de periódicos para os
Assinantes, de modo sincronizado com a logística.
Módulo de TMC ( Total Marketing Coverage )
Deve, por exemplo, suportar o processo de distribuição de produtos para uma
determinada região geográfica, podendo esta ser segmentada em função das
características de cada residência.
7.1.3 MODELO DE RELACIONAMENTO PROPOSTO PARA O CLIENTE DA
EMPRESA Y
No modelo de serviços proposto, a Empresa Y manterá um Engenheiro de Requisito
(Analista de Sistemas Sênior), que deverá garantir o entendimento e manter a
140
documentação dos requisitos gerados por usuários e equipes do Cliente. Este
Engenheiro deverá encaminhar para a equipe de projeto da Empresa Y, nas fases de
Levantamento e Análise, os documentos de especificação de requisitos e casos de uso,
além de registrar e negociar nas fases seguintes as solicitações de mudanças
encaminhadas pelos usuários/analistas do Cliente.
Como pré-requisitos tem-se o desenvolvimento orientado a objetos, três camadas
(interface, aplicação e banco de dados), a utilização da técnica de use case e um processo
baseado no RUP – Rational Unified Process.
Figura 38 – Modelo de relacionamento entre equipes.
Cliente Empresa Y
Gerente Comercial
Líder de Projeto
Equipe de
Analistas/Progrs
Gerente do Projeto
Staff de Sistemas e
Representantes do Grupo
de Usuários
Engenheiro
Requisitos Produtos Validados
Requisitos, Termos
de Aceitação
Planos de Trabalho,
Relatórios
141
A REUTILIZAÇÃO
Para realizar a reutilização algumas ações foram realizadas:
Definindo o objetivo da reutilização: Discutiu-se como deveria ser o processo de
engenharia de requisitos para o tipo de projeto. Definiu-se que ele deveria ser um que
empregasse a técnica de casos de uso, planejamento de iterações (tendo como base o ciclo
de vida espiral) e possuísse gerenciamento de requisitos (rastreamento e mudanças).
A busca: Realizou-se uma análise da base de processos, na ferramenta de reutilização,
com o objetivo de identificar qual dos processos ou atividades poderiam ser reutilizados.
Conclui-se que o processo simplificado da Rational poderia ser reutilizado, era o mais
similar, e que a reutilização seria quase que total. Entretanto outras atividades deveriam
ser introduzidas e algumas existentes retiradas.
Figura 39 – Processo Simplificado da Rational.
142
A decisão do tipo de reutilização: Optou-se então em realizar a reutilização total e
posteriormente fazer a reorganização do processo segundo a forma que ele seria utilizado
na empresa e com o número de atividades macro segundo a qual a empresa já imaginava.
A reutilização e a adaptação - Decisões tomadas/ Reutilizações:
ü Acrescentou-se o processo macro gerenciar requisitos de Kotonya: Gerenciar
mudanças e gerenciar o relacionamento entre os requisitos – o que gostou-se foi mais
a estrutura do que a informação propriamente dita. Desta forma, o sub-processo
gerenciar mudanças de requisitos, da Rational, tornou-se Gerenciar Requisitos
incluindo gerenciar mudanças e dependências de requisitos.
Tabelas auxiliares:
1. Política: não foi possível reutilizar, pois é específica da organização e a
descrita na ferramenta estava voltada muito mais para gerência de requisitos.
2. Funções: todas as funções necessárias estavam definidas na base e foram
reutilizadas, com exceção da função revisor de requisitos.
3. Ferramentas: Todas estavam descritas e foram reutilizadas.
4. Conceitos: Cerca de 60% dos conceitos já estavam definidos e foram
reutilizados.
5. Formulários: foram utilizados os da Rational com uma tradução e adaptação.
Não estavam disponíveis na base de dados.
6. Medição: as medições foram definidas pela empresa.
7. Verificação: utilizou uma existente na base e que estaria de acordo com o
modelo CMM
8. Método/Técnica: foram reutilizadas as técnicas de entrevistas e workshop de
requisitos
9. Artefatos: cerca de 60 % foram reutilizados, outros foram definidos.
10. Treinamento: Os treinamentos definidos foram reutilizados do repositório.
143
ü O processo: Reutilizou-se o processo como um todo e para as atividades que faltavam
foi realizada uma pesquisa na base de dados. O framework foi de grande valia visto
que traz de forma organizada , os prováveis componentes que podem ser reutilizados.
ü Na adaptação utilizou-se parte do processo de Kotonya e Sommerville na parte de
Gerenciar requisitos, substituindo o Gerenciar mudanças nos requisitos do processo
simplificado da Rational. Na figura que segue mostra-se os dois subprocessos. Após
ter reutilizado algumas informações das descrições das atividades o subprocesso
gerenciar mudanças de requisitos foi excluído.
Figura 40 – Processo da Empresa Y sendo definid: atividades similares.
ü Uso de um Process Standard: Na definição da atividade revisão realizou-se um
“merge” entre a descrição da atividades do usual process reutilizado (rever requisitos)
com um process standard do CMM (revisar requisitos alocados) – Figura 41, que
segue, permanecendo com o nome e as outras informações desta última atividade
(process standard). Também foi necessário passar algumas entradas e saídas que o
usual process possuía que no process standard não estavam definidos, como por
144
exemplo, as entradas modelo de use case e glossário de termos. Após a reutilização a
atividade “rever requisitos” do processo simplificado Rational foi excluída. Também
foi utilizada a atividade controlar alterações nos requisitos, embora seu nome tenha
sido modificado para permanecer o nome de acordo com o processo anteriormente
reutilizado de Kotonya e Sommerville.
Figura 41- Reutilizando atividades de um Process Standard.
ü Uso de um Process Pattern: Também foram reutilizadas as descrições do process
pattern gerenciar as expectativas do cliente (atividade macro) e a atividade produzir
lista de expectativas do cliente (Figura 42) – foram embutidas na descrição das
atividades entender as necessidades dos stakeholders e elicitar requisições dos
stakeholders, respectivamente. Após a análise e reutilização das descrições as
atividades do process pattern foram excluídas.
Na Figura 42 também se percebe que, no lado direito, existe a origem, ou seja, mostra a
formação do atual processo (Processo Estudo de Caso da Empresa Y): formado por
atividades originadas de process standard, process pattern e usual process.
145
Figura 42 – Processo da Empresa Y com as atividades de um Process Pattern.
ü Complementação: As descrições das atividades foram reutilizadas e geralmente
complementadas de acordo com as necessidades da Empresa Y. Por exemplo,
entradas, saídas e métodos/técnicas.
O resultado do estudo de caso – o processo de engenharia de requisitos – encontra-se no
Anexo D. De forma conclusiva a Empresa Y achou que a proposta de reutilização é
viável com pequenas melhorias e que o nível de reutilização alcançado foi alto. O tempo
consumido conhecendo os conceitos da arquitetura de processos proposta, a ferramenta,
analisando os processos existentes na base, realizando revisões com o gerente do projeto
e realizando a definição foi de 56 horas. O especialista de processos da Empresa Y
definiu como sendo um tempo ótimo visto que ele esperava de 180 a 360 horas.
146
EXPERIMENTO
O experimento foi realizado com o intuito de verificar o uso da arquitetura proposta. Seis
alunos da disciplina de Engenharia de Requisitos da PUC, semestre 2001-1, que
participaram em duplas, deveriam montar um processo de engenharia de requisitos, o
qual seria utilizado em suas empresas fictícias, considerando apenas a reutilização das
atividades sem realizar adaptações. Para definir o processo eles utilizariam o protótipo da
ferramenta de reutilização. Eles poderiam optar por definir um processo a partir do
framework ou a partir da reutilização livre – parcial. Todos eles tinham apenas uma noção
de um processo de engenharia de requisitos e também receberam apenas instruções
rápidas do uso (20 minutos). Os três grupos finalizaram a definição com os seguintes
tempos:
- Grupos A reutilizou usando framework: 1 hora
- Grupo B reutilizou usando framework: 1 hora e 20 minutos
- Grupo C reutilizou usando pesquisa parcial: 2 horas
Um especialista em requisitos também participou definindo um processo, com poucas
adaptações, utilizando a reutilização livre parcial. O seu tempo foi aproximadamente 1
hora.
Embora a complexidade dos processos possam ser diferentes, pois não foram
estabelecidos critérios de definição, estes são alguns parâmentros de tempo onde observa-
se que definir através do framework traz um aumento de produtividade, tendo em vista a
reutilização.
Os resultados quanto a viabilidade da proposta e o nível de reutilização foram:
Grupo A Grupo B Grupo C Especialista
Viabilidade com melhorias
na ferramenta
com poucas
melhorias
Completamente
viável
com melhorias na
ferramenta
Nível de
reutilização
Alto Alto Médio Alto
147
Apenas um grupo, que definiu pela reutilização livre-parcial, achou que o nível de
reutilização foi médio. Percebeu-se que este grupo definiu novas atividades.
Como sugestões os grupos e especialista acreditam que o tempo de reutilização pode ser
melhorado se:
§ for melhorada a interface;
§ se existir um tempo prévio de aprendizado da utilização do protótipo;
§ se existir um tempo prévio maior para entendimento dos conceitos do que são os
diferentes tipos de processos, sua estrutura e a navegação na ferramenta.
148
Capítulo 8 – Conclusões e Trabalhos Futuros
Este capítulo apresenta as conclusões desta tese, descreve as contribuições realizadas e sugere
trabalhos futuros.
CONCLUSÕES
Bill Curtis [90] no seu artigo “The Global Pursuit of Process Maturity” descreve que a
década de 90 foi a da melhoria de processos de software e que a década de 2000, será a
do controle, o da supremacia (mastery) dos processos de software. Isto se conseguirá
centrando-se na integração, harmonia e aceleração dos processos de desenvolvimento e
manutenção de software. Entre as mudanças, relata-se que os desenvolvedores terão que
criar processos flexíveis que possam ser adaptados para realizar a integração com os
processos de aquisição de software de terceiros - integração. Os desenvolvedores também
deverão harmonizar seus processos com elementos similares, divididos entre vários
padrões (standards) de processo, com o objetivo de acompanhar como seus processos
satisfazem estes padrões – harmonia. Desenvolvedores terão que reduzir seus processos
para elementos essenciais, e melhorar a coordenação destes, enquanto ainda conseguem
alcançar metas de qualidade e orçamento – aceleração.
Acredita-se que a arquitetura proposta nesta tese vem de encontro a essas previsões.
Obter a flexibilidade dos processos para que eles possam ser adaptados aos diferentes
clientes, ou mesmo aos diferentes projetos internos, requer um grande esforço. Ter
linguagens de modelagem de processos e uma organização para a reutilização dos
processos é fundamental para a agilidade, implementação e alcance deste objetivo.
Referindo-se a harmonia, a arquitetura apresentada integra três questões fundamentais
relacionadas com os processos: standards (o que a comunidade define que deve ser
seguido por determinados processos), patterns (relatos de soluções para problemas
relacionadas a processos) e frameworks (conhecimento de um determinado domínio
organizado e disponibilizado). Eles estão apresentados de uma forma simples e conhecida
– processos. Unindo-se a estas questões, integra-se o conhecimento disponível na
149
organização, mercado e na literatura, através do usual process. Isto é básico para
vislumbrar a “aceleração” definida por Bill Curtis.
Esta proposta está distante de solucionar todos os problemas em processos, mas as
conclusões servem de base para futuras pesquisas. A seguir, apresentam-se as principais
conclusões de acordo com os principais capítulos desta tese.
8.1.1 A ARQUITETURA PROPOSTA
Conseguiu-se implementar a arquitetura proposta, integrando-se os diferentes tipos de
processos e os frameworks de processo. A definição de um núcleo comum entre os tipos
de processos possibilitou a reutilização automática de atividades no seu nível detalhado,
tornando-as componentes reutilizáveis dos processos. Para os processos do tipo usual a
reutilização foi mais ampla, podendo-se reutilizar automaticamente todos os dados.
Devido a organização, também foi possível utilizar os process patterns e os process
standards (parte equivalente as atividades detalhadas) e os usual processes (atividades
macros e detalhadas) como componentes do framework.
Referente ao uso da arquitetura, implementou-se e mostrou-se a diferença de uma
reutilização baseada em uma pesquisa livre, onde o engenheiro de processos procura
pelos seus processos/ componentes, e uma baseada em framework, onde o engenheiro de
processos recebe a indicação dos componentes e tem guias de reutilização.
8.1.2 LINGUAGENS DE MODELAGEM DE PROCESSOS
As linguagens de modelagem de processos foram definidas na meta-linguagem XML sem
muitas dificuldades. Foram também definidas três DTDs (gramática), uma para cada tipo
de processo. Buscaram-se documentos de processos que pudessem ser representados e
manipulados de forma independente.
Referindo-se aos elementos definidos para os processos, constatou-se através do uso,
quando da formação da base de dados inicial de processos de engenharia de requisitos,
que muitos processos mapeados preencheram muito pouco dos elementos definidos pela
150
linguagem, principalmente no caso de usual process. Exemplos são as medições,
verificações, formulários, pré-condições e pós-condições. Além disso, confirma-se que a
engenharia de requisitos ainda não tem processos suficientemente maduros para definir
todos estes atributos. Isto talvez esteja ligado a maturidade dos processos. Também, como
esperado, a definição de dados de contexto do processo (usual process) – elemento
característica –, definido para dar suporte à instanciação dos processos, só era preenchido
(sua maioria) para aqueles processos provenientes de casos práticos da indústria.
Utilizando-se uma base única de artefatos, conceitos e funções – obteve-se maior
consistência – embora tenha-se encontrado dificuldade em mantê-la devido a diversidade
de entradas e saídas com estados diferentes (como, por exemplo, documento de requisitos
documentado, revisado e assinado).
8.1.3 DESENVOLVIMENTO DE FRAMEWORKS DE PROCESSO
Foi possível aplicar o processo definido, embora se tenha encontrado dificuldades em
estabelecer os conceitos de hot-spots e pontos comuns (uma atividade macro pode ser
comum, mas pode ter atividades detalhadas opcionais; e uma descrição de atividade igual
a outra é quase impossível). Outra dificuldade, no caso da engenharia de requisitos, foi
que, devido a diversidade e pouca similaridade entre as atividades detalhadas, obteve-se
um grande conjunto de atividades opcionais. Optou-se por simplificar o framework,
excluindo-se as atividades que eram muito específicas de um processo e que eram
associadas com técnicas (como, por exemplo, priorizar use cases). Cabe salientar que a
definição do framework foi uma atividade bastante trabalhosa, mas foi igualmente válida
por sistematizar a análise de domínio para processos.
No que se refere a trabalhos relacionados, o mais próximo é a pesquisa de Hollenbach &
Frakes [29] onde eles definem um método para elaborar processos reutilizáveis. O
objetivo do método é “desenvolver e manter um conjunto de descrições de processos de
software que melhoram o desempenho de processos através dos projetos e fornecer uma
base cumulativa de benefícios em longo prazo para a organização”. Entretanto, eles
151
também não definem em detalhes como realizar a análise do domínio e não fazem uso de
guias de reutilização.
A atividade de análise do processo proposta é similar, pois eles também funcionam com a
idéia de definição de processos reutilizáveis genéricos, analisando processos de projetos
específicos e dados de processos relevantes da indústria. Hollembach & Frakes [29]
buscam determinar similaridades, variações e combinações que ajudam a estruturar o
processo para a reutilização. No entanto, como foi mencionado anteriormente, não
especificam como fazer – o que difere desta proposta. As atividades de design
apresentadas por eles referem-se a definição de atividades macro e detalhadas, seguindo a
linguagem de modelagem de processos por eles estabelecida. Isto é semelhante a proposta
deste trabalho, sendo que a linguagem definida nesse trabalho está sistematizada e é
muito mais rica em elementos relacionados aos processos, podendo-se estabelecer de
processos mais simples a processos mais complexos – no que tange a sua documentação.
Como não está no escopo dessa tese a automação de processos, não foram abordadas as
seguintes atividades: teste de unidade e código de processo, teste e integração de
processo, por eles abordados.
Pode-se também comparar o processo proposto, no que se refere à definição dos hot
spots, com a definição de Fontoura [48]. Fontoura propôs uma extensão na notação UML,
voltada para frameworks de aplicação, para acomodar uma representação que pudesse
descrever o design de frameworks. Sua definição permite a flexibilização em vários
níveis, ou seja, pode-se modificar a implementação de um método, criar novos métodos
ou, definir classes nas instâncias do framework. Nessa tese, modificar a implementação
de um método é o equivalente a redefinir os elementos [OP]cionais do framework;
redefinindo as descrições existentes, criando novas descrições ou, na maioria das vezes,
reutilizando componentes existentes. Criar novos métodos é o equivalente a adicionar
novas atividades detalhadas a uma atividade macro existente. Criar novas classes é o
equivalente a criar novas atividades macros quando da complementação do processo.
Percebe-se que no caso de frameworks de processo, quando se refere a reutilização de
152
descrições e não de código, mesmo a atividade sendo um ponto comum, pode ser que ela
receba complementações ou pequenas alterações após sua reutilização.
De forma sucinta, no que se refere ao uso dos conceitos provenientes dos estudos de
frameworks de aplicação, pode-se então fazer a seguinte equivalência:
Frameworks de aplicação Frameworks de processo
Identificação dos pontos de flexibilização em por
exemplo, hot spot cards ou extensões UML
Identificação em guias de reutilização
Framework = código Framework = descrições de processo
Interface Entradas e saídas
Fluxo de controle Representação do processo com atributo descrevendo
o fluxo de controle
Classes Elementos do processo (DTD)
Substituição dos hot spots em tempo de criação
ou execução
Substituição sempre em tempo de criação
Reutilização caixa-branca Alteração das descrições das atividades opcionais e
definição de outros elementos do processo.
Reutilização caixa-preta – componentes “pré-
fabricados”
Componentes definidos no guia de reutilização
(atividades provenientes dos tipos de processos)
Conclui-se que, pelo fato de frameworks de processos estarem num nível de abstração
bastante diferente dos frameworks de aplicação, aplicou-se muito dos conceitos, ainda
que implementados de forma diferente e muitas vezes não tão nítidos quanto em
frameworks de aplicação.
Encontrou-se dificuldade de implementar o guia, no que se referiu a definição de
componentes para substituir uma atividade. Definiu-se que a regra era uma atividade que
poderia ser substituída por um componente. Entretanto, algumas atividades do framework
eram mais genéricas e muitas vezes, para serem cobertas, deveriam ser atendidas por
mais de um componente. O inverso também ocorreu. Algumas atividades no framework
eram mais detalhadas, por exemplo, em vez de ter uma atividade realizar a validação de
“x” optou-se por ter validar “x-a” e validar “x-b”. Muitas vezes estas atividades tinham
153
um componente que a abordavam, mas também abordavam outras questões14. Para
viabilizar, manteve-se então somente aquelas atividades que poderiam respeitar a regra
uma atividade é substituída por um componente.
CONTRIBUIÇÕES
As principais contribuições deste trabalho estão relacionadas com a arquitetura de
processos definida, envolvendo as linguagens de modelagem de processos, os diferentes
tipos de processos e o uso dos conceitos de frameworks e os seus guias de reutilização.
Os dados de processos de engenharia de requisitos disponibilizados para a comunidade,
na forma de process patterns, process standards e framework de processos também são
importantes para divulgação da Engenharia de Requisitos e para a elaboração de novos
processos.
8.1.4 A ARQUITETURA PARA REUTILIZAÇÃO DE PROCESSOS DE SOFTWARE
Disponibilizou-se uma arquitetura para reutilização de processos de software integrando-
se e organizando-se diferentes conceitos (patterns, standards, frameworks, guias de
reutilização, facetas e linguagens – XML/DTD ) que viabilizam, de forma sistemática e
prática, a reutilização de processos.
Uma das preocupações de pesquisas correntes [45] é como ter processos que possam ser
adaptados para as diferentes necessidades dos projetos. Com a arquitetura, através da
reutilização, é possível obter uma diversidade de modelos de processos que podem ser
originados de um ou mais processos que estejam na base de dados. Estes modelos de
processos originados podem ser adaptados e/ou complementados, de acordo com as
necessidades dos projetos e de acordo com as características da organização. Além disto,
existem opções que podem ser selecionadas para realizar a reutilização, ajustando-se as
necessidades correntes de quem reutiliza:
14 Percebe-se que, como comentado, ter descrições iguais é quase impossível, no entanto o que se refere é
que não se pode ter atividades com um escopo muito diferente.
154
a) a reutilização livre - parcial, permitindo buscas mais específicas e podendo-se
reutilizar dados de process patterns (solucionado algum eventual problema ou
reutilizando experiências), process standards (tendo-se a necessidade de definir o
processo conforme um padrão) e usual process (reutilizando dados da organização,
mercado ou literatura);
b) a reutilização de um processo existente – total, reduzindo o trabalho de definição;
c) a reutilização através de um framework; oferecendo um processo que foi definido
através de uma análise do domínio e que pode ser redefinido e complementado de
acordo com as necessidades de quem reutiliza. Também oferece componentes pré-
definidos e selecionados que podem preencher pontos de flexibilização do framework,
reduzindo trabalhos de busca, e guias de reutilização que auxiliam na instanciação do
framework.
Na arquitetura, os diferentes tipos de processos (standards, patterns e usual) são
definidos com a meta linguagem XML (Extensible Markup Language), aproveitando-se
de suas facilidades de funcionar com estruturação de documentos, o que é adequado para
processos, visto a natureza hierárquica deles. Pelo fato da especificação das linguagens de
processos estar em XML, elas podem ser usadas para definir documentos XML (modelos
de processos), independente do protótipo da ferramenta de reutilização apresentada. As
linguagens em XML são fontes de informação flexíveis que podem ser facilmente
modificadas e reorganizadas. A linguagem, por contar com muito elementos, torna-se
bem flexível podendo-se ter modelos de processos dos mais simples aos mais detalhados.
A organização dos diferentes tipos de processos para viabilizar a reutilização e a
recuperação de informações, foi certamente uma contribuição. Foi possível definir formas
de recuperação de dados dos processos, desde o uso de palavras-chaves, facetas, escolha
em combo box (pois elementos possuíam classificação), até o uso da própria estruturação
dos diferentes tipos de processos.
155
A utilização dos conceitos de frameworks de aplicação na arquitetura, para definição de
frameworks de processos, foi um desafio – devido a diferença nos níveis de abstração dos
objetos manipulados. No framework de aplicação reutiliza código, enquanto o outro
reutiliza descrições de processos. Portanto, contribui-se mostrando as possibilidades de
uso destes conceitos a processos e as dificuldades apresentadas. Conseguiu-se organizar
os processos de forma que suas atividades representem componentes que podem ser
reutilizados, podendo-se definir uma diversidade de modelos de processos. Também se
definiu uma estrutura de guias de reutilização que podem ser aplicados juntamente com
os frameworks de processos.
8.1.5 ENGENHARIA DE REQUISITOS
Para que a arquitetura proposta pudesse ser validada, um protótipo de uma ferramenta
WEB foi desenvolvido, dando suporte à atividade de cadastro de dados de processos e
viabilizando a reutilização segundo os conceitos definidos. Desenvolveu-se um esquema
sistemático de organização e acesso à base de dados de processos com o objetivo de
permitir uma melhor busca, seleção e evolução da base de dados. Utilizaram-se as facetas
e os próprios elementos e organização dos processos (como, por exemplo, a sociedade de
process patterns e a estruturação de sua solução). Sendo assim, foi possível disponibilizar
para a comunidade uma base de dados inicial de processos para a área de engenharia de
requisitos, apresentando-se os diferentes tipos de processos, que poderão ser reutilizados
e adaptados, quando necessário. Também se disponibilizou um framework de processo de
engenharia de requisitos, baseado em uma análise de domínio, que poderá ser reutilizado
ou ser objeto de futuros estudos. O próprio protótipo, embora não sendo objetivo da
pesquisa, também é uma contribuição. Ele implementa as funcionalidades básicas que
permitem a reutilização dos processos.
Um exemplo desta contribuição é a utilização da ferramenta de reutilização e os
processos pelo grupo de estudos da Universidade Sevilla e Valencia, na Espanha . Essa
utilização está descrita em um artigo submetido ao Workshop de Engenharia de
156
Requisitos e disponibilizado como relatório técnico do Departamento de Informática da
PUC-Rio [109].
TRABALHOS FUTUROS
Como trabalhos futuros indicam-se, entre outros, estudos de caso, a consideração da
gerência de configuração e adaptação de processos, a melhoraria nos guias de
reutilização, o teste do uso da ontologia na pesquisa e recuperação de informações dos
processos e evolução do protótipo da ferramenta, finalizando-o e acrescentando-se novas
funcionalidades. A seguir, descrevem-se estas sugestões.
8.1.6 ESTUDOS DE CASO
Motivar empresas, disponibilizando a ferramenta na WEB, por mais tempo, para que elas
utilizem os dados e definam seus processos, obtendo-se mais informações sobre as
características dos processos (geralmente definidas na prática), o que é fundamental para
a reutilização. Também se estará coletando mais dados para o banco de dados e para as
medições dos níveis de reutilização. Outro estudo de caso que pode ser realizado é
utilizar processos mais simples e maduros que podem ser melhor detalhados e
implementados e, aplicar uma reutilização baseada na representação EPC (event-
controlled process chain), descrita no modelo SAP/R3 [2], verificando o que precisa ser
alterado na arquitetura apresentada.
8.1.7 GERÊNCIA DE CONFIGURAÇÃO E ADAPTAÇÃO DOS PROCESSOS
Nesta tese, questões ligadas ao controle de versões e mudanças dos processos e ligadas a
como adaptar (evoluir) processos não foram ênfase. Portanto, elementos necessários para
manter o controle de versões e mudanças precisam ser definidos e refletidos na
linguagem de modelagem dos diferentes tipos de processos.
A questão da adaptação dos processos (complementação) deve ser melhor estruturada.
Por exemplo, quando se reutiliza um formulário, a instância de processo criada aponta
para um formulário do elemento auxiliar “Formulário”. No entanto, para modificá-lo,
deve-se editá-lo e salvá-lo como um outro documento, mantendo o relacionamento com a
157
instância. Isto ainda não está implementado. Além disso, como considerar aspectos
culturais e organizacionais também são questões a serem acrescentadas.
8.1.8 GUIAS DE REUTILIZAÇÃO
Os guias de reutilização podem ser melhorados. Por exemplo, para cada componente que
pode substituir uma atividade, embora se tenha fácil acesso a seus dados, poder-se-ia
identificar no guia, palavras-chaves ou algo do gênero para identificar rapidamente o que
ele realiza, antes de consultá-lo ou reutilizá-lo.
Para se ter uma visão geral e melhorar o entendimento do que se pode reutilizar, poder-
se-ia ter um guia comparando os diferentes process standards e um guia mostrando o
framework de processo versus os diferentes usual processes armazenados na base.
Trabalhando melhor a questão de componentização, é indicado verificar como os
problemas relacionados com a reutilização dos componentes (de acordo com a regra
“uma atividade só pode ser substituída por um componente”) podem ser melhor
abordados.
8.1.9 PESQUISA E RECUPERAÇÃO DE INFORMAÇÕES
A ontologia tem mostrado [91] que se pode auxiliar na organização e recuperação das
informações. Portanto, verificar como a ela pode ser aplicada evoluindo mais o uso de
facetas e montando-se grafos com o conhecimento dos processos, pode ser um ponto de
partida.
8.1.10 EVOLUÇÃO DO PROTÓTIPO DA FERRAMENTA
O protótipo da ferramenta pode melhorar, sendo finalizado e acrescentando-se novas
funcionalidades. Desenvolver a parte gráfica da representação de processos, como, por
exemplo, um editor gráfico com diferentes modelos de representação de processos
(similar a ferramenta Áris [92]), pode auxiliar na comparação e adaptação dos processos.
Uma natural evolução é armazenar e recuperar processos no formato XML e aplicar
conceitos de orientação a objetos. Dispor de vários tipos de arquivos “.xsl”, que tratem da
158
apresentação do processo em um browser facilitando a reutilização da apresentação dos
processos gerados, também é um item que pode ser incluído.
Finalmente, podem ser providas ao usuário final funcionalidades para a edição de
frameworks de processos. No entanto, deve-se considerar a reutilização de processos/
atividades existentes na base de dados. Além disso, deve-se verificar as mudanças
necessárias nas linguagens para esta implementação.
8.1.11 OUTRAS SUGESTÕES
Ainda, como outras sugestões futuras, pode-se ter guias para os diferentes tipos de
processo, descrevendo, por exemplo, heurísticas associadas as atividades ou dicas.
Também pode-se utilizar o LAL – Léxico Ampliado da Linguagem [93] no elemento
Conceito (elemento auxiliar do processo) – mostrando seus sinônimos, fonte da definição,
ligações entre os conceitos do processo, enriquecendo a semântica para entendimento do
processo.
159
Referências
[1] Humphrey, W.S.; Managing the Software Process; Addison Wesley; ISBN 0-201-18095-2, 1989.
[2] Keller, G., Teufel, T.: SAP R/3 Process Oriented Implementation, Addison-Wesley, 1998.
[3] http://www.informatik.uni-bremen.de/uniform/vm97/conferences/ispw01.htm
[4] ISPW - http://www.informatik.uni-bremen.de/uniform/vm97/conferences/i-ispw.htm
[5] ICSP - http://www.informatik.uni-bremen.de/uniform/vm97/conferences/i-icsp.htm
[6] IPTW - http://www.informatik.uni-bremen.de/uniform/vm97/conferences/i-iptw.htm
[7] http://www.informatik.uni-bremen.de/uniform/vm97/conferences/i-ewspt.htm
[8] FEAST - http://www.doc.ic.ac.uk/~mml/f2000/
[9] http://www.informatik.uni-bremen.de/uniform/vm97/conferences/i-profes.htm
[10] SIG - http://www.informatik.uni-bremen.de/uniform/vm97/books/b0002.htm
[11] Anais Simpros: II Simpósio Internacional de Melhoria de Processo de Software, 2000.
[12] SEPG - http://www.sei.cmu.edu/products/events/sepg/
[13] http://www.cos.ufrj.br/~spin-rio/
[14] Osterweil, L.: Software Process are Software too, Proceedings of the 9th International Conference on Software Engineering, 1987.
[15] Ambriola, V., Conradi, R., Fuggetta, A.: Assessing Process-Centered Software Engineering Environments, ACM Transactions of Software Engineering and Methodology, 6 (3), pp 283-328, 1997.
[16] Karrer, A S. and Scacchi, W.: Meta-Environment for Software Production, Information and Operation Management Departament, University of Southern California, 1994.
[17] Paulk, C.M., Curtis, B., Chrissis, M. B., Weber, V.C.: Capability Maturity Model for Software, Ver. 1.1, Software Engineering Institute, Carnegie Mellon University, CMU/SEI-93-TR-24, ESC-TR-93-177, 1993.
[18] Konrad, M. and Paulk, M.: An Overview of SPICE’s Model for Process Management, Proceedings of the International Conference on Software Quality, October, Austin, TX, pp 291-301, 1995.
[19] The Trilhum Model, http://www2.umassd.edu/swpi/BellCanada/trillium-html/trillium.html
[20] Haase, V. et al, Bootstrap: Fine-Tuning Process Assessment, IEEE Computer, Vol. 27, Number 17, pp 25-35, July 1994 – http://www.bootstrap-institute.com/
[21] Ambler, S. W.: Process Patterns – Building Large-Scale Systems Using Object Technology, Cambridge University Press/ SIGS Books, 1998.
[22] Wills, A. C.: Process Patterns in Catalysis, http://www.trireme.com/catalysis/procPatt
160
[23] Berger, K. at all : A Componentware Development Methodology based on Process Patterns, OOPSLA 98, 1998.
[24] Vasconcelos, F. and Werner, C.M.L: Organizing the Software Development Process Knowledge: An Approach Based on Patterns, International Journal of Software Engineering and Knowledge Engineering, Vol. 8, Number 4, 461-482, 1998.
[25] Coplien, J. O.: A Generative Development Process Pattern Language, in PloP, 1995.
[26] Whitenack, B., RAPPeL: A Requirements-Analysis-Process Pattern Language for Object-Oriented Development, in PloP, 1995.
[27] Castano, S., De Antonellis, V., Reusing Process Specifications, in Proceedings of the IFIP WG8.1 Working Conference on Information System Development Process, Como, Italy, 1993.
[28] Henninger, S., An Environment for Reusing Software Processes, International Conference on Software Reuse, pp 103-118, 1998.
[29] Hollenbach, C., Frakes, W.: Software Process Reuse in an Industrial Setting, Fourth International Conference on Software Reuse, Orlando, Florida, IEEE Computer Society Press, Los Alamitos, CA, pp 22-30, 1996.
[30] Frakes W.B., Gandel, P.B., Representing Reusable Software, Information and Software Technology, 32 (10), pp – 653-664, 1990.
[31] Kruger, C.W. Software Reuse, Computing Surveys, 24(2), 00 131-183, 1992.
[32] Mili, H., Mili, F., Mili, A., Reusing Software: Issues and Research Directions, Transactions on Software Engineering, 21(6), pp 528-562, 1995.
[33] Gamma, E., Helm, R., Johnson, R., e Vlissides, J.: Design Patterns: Elements of Reusable Object-Oriented Design, Addison-Wesley, 1995.
[34] Pree, W.: Framework Patterns, New York: SIGS Books, 1996.
[35] Buschmann, F., Meunier, R., A System of Pattern, Pattern Language of Program Design, Vol 1, edited by Copien and Schimidt, Addison-Wesley, 1995.
[36] Coplien, J. O.: Software Patterns, SIGS Books & Multimedia, USA 1996.
[37] Jacobson, I., Griss, M., Jonsson, P., Software Reuse. Architecture, Process and Organization for Business Success, Addison Wesley, 1997.
[38] Prieto-Díaz, R.: Implementing Faceted Classification for Software Reuse, Software Engineering Notes, Vol. 34, no. 5, May , pp 88-97, 1991.
[39] Paulk, C.M., Curtis, B., Chrissis, M. B., Weber, V.C.: Capability Maturity Model for Software, Ver. 1.1, Software Engineering Institute, Carnegie Mellon University, CMU/SEI-93-TR-24, ESC-TR-93-177, 1993.
[40] Fiorini, S. T., Staa, A.,Baptista, R. M.: Engenharia de Software com CMM, Brasport, 1998.
[41] SEI, Process Maturity Profile of the Software Community 1999 Year End Update, SEMA 3.00, Carnegie Mellon University, March 2000.
[42] Fiorini, S.T., Leite, J.C.S.P, Lucena, C.J.P.: Reusing Process Patterns, Proceedings of the Workshop on Learning Software Organizations, Oulu 2000.
161
[43] Henninger, S.: Using Software Process to Support Learning Organizations, Proceedings of the Workshop on Learning Software Organizations, Kaiserslaurten, Germany, 1999.
[44] Ginsberg, M. L., Quinn, L.: Process Tailoring and the Software Capability Maturity Model, Technical Report, http://www.sei.cmu.edu/publications/documents/94.reports/ 94.tr.024., (CMU/SEI-94-TR-024), 1994.
[45] Rolland, C., Prakash and Bejamen, A.: A Multi-Model View of Process Modeling, Requirements Engineering, Springer-Verlag London Limited, 4, 169-187, 1999.
[46] Kruchten, P., The Rational Unified Process an Introduction, Addison-Wesley Object Technology Series, 1999.
[47] Fayad, W.E., Schmidt, D,C., Johnson, R.E., Building Application Framework, ISBN 0471-24875-4, 1999.
[48] Fontoura, M. F. M. C.: A Systematic Approach to Framework Development, Tese de Doutorado, Departamento de Informática, PUC-Rio, 1999.
[49] Fowler, P., Patrick, M., Carleton, A. and Merrin, B.: Transition Packages – An Experiment in Expediting the Introduction of Requirements Management, Proceedings of ICRE – Third International Conference on Requirements Engineering, IEEE Computer Society, California , 138-145, 1998.
[50] XML - http://www.w3.org/TR/REC-xml
[51] ABNT: NBR ISO/IEC 12207 – Tecnologia de Informação – Processos de ciclo de vida de software, Outubro, 1996.
[52] Fiorini, S. T., Processos de Negócio e Hipertextos: uma proposta para elicitação de requisitos, Dissertação de Mestrado, Departamento de Informática, PUC-Rio, 1995.
[53] Fiorini, S.T., Leite, J.C.S.P, Macedo-Soares, T.D.L.: Integrating Business Processes with Requirements Elicitation, Proceedings of the 5th Workshops on Enabling Technologies: Infrastructure for Collaborative Enterprises (WET ICE’96), 1996.
[54] Citibank Brasil, Process Quality Manual v 4.0 (I – Política de Engenharia de Software e Processo de Software Padrão, II – Gerência do Processo e III – Engenharia do Produto), SEPG, 1999.
[55] McIlroy, M. D., Mass-produced Software Components, In J. M. Buxton, P. Naur and B. Randell editors, Software Engineering Concepts and Techniques; Van Nostrand Reinhold (1968 NATO Conference on Software Engineering), pp 88-98, 1976.
[56] Appleton, B.: Patterns and Software: Essential Concepts and Terminology, http://st-ww.cs.uiuc.edu/users/patterns/patterns.html
[57] Fowler, M.: Analysis Patterns: Reusable Objects Models, Addison-Wesley, 1997.
[58] Coplien. J. O. – http://www.bell-labs.com/user/cope/Patterns/Process/index.html
[59] Rising, L.:, A Way to Reuse Expertise, IEEE Communications Magazine, Vol 37, No 4, April, 1999.
[60] Girardi, R., Main approaches to software classification and retrieval, em Cursos Complementarios 1998 - Ingeniería de Software y Reutilización: Aspectos Dinámicos y Generación Automática, Universidade de Vigo, Santiago,1998.
162
[61] XSL – http://www.w3.org/TR/WD-xsl
[62] Guerrieri, E.: Software Document Reuse with XML, Proceedings Fifth International Conference on Software Reuse, Victoria, Canadá, IEEE Computer Society, 246-254, 1998.
[63] http:// msdn.microsoft.com/xml e http:// msdn.microsoft.com/xml/xslguide
[64] www.webreference.com/xml/column1/page2.html
[65] Finkelstein, A., Kramer, J., Nuseibech, B.,: Software Process Modelling and Technology, Research Studies Press Ltda e John Wiley & Sons Inc, 1994.
[66] Fiorini, S.T., Leite, J.C.S.P., Lucena, C.J.P.: Describing Process Patterns, Monografias em Ciência da Computação no. 13/99, PUC-Rio, Agosto 1999.
[67] Alexander, C., The Timeless Way of Building, New York: Oxford University Press, 1979.
[68] Fiorini, S.T., Leite, J.C.S.P., Lucena,C.J.P.:Reutilizando Processos com XML/XSL, Anais do II Simpósio Internacional de Melhoria de Processos de Software - SIMPROS, São Paulo, Setembro, 2000.
[69] ANBT: NBR ISO 9000-3 – Normas de gestão da qualidade e garantia da qualidade, Nov. 1993.
[70] http://informatik.uni-bremen.de/uniform/vm97/gdpa02.htm
[71] Kang, K. et al., Features-Oriented Domain Analisys – Feasibility Study, In SEI Technical Report CMU/SEI-90-TR-21, November 1990.
[72] Lator, L.,Wheeler, T., Frakes, W.:Descriptive e Prescriptive Aspects of the 3C’s Model: SETA1 Working Group Summary. Ada Letters, XI(3), pp 9-17, 1991.
[73] Miler Jr, N. Werner, C.M.L., Braga, R.M.M.: O uso de modelos de Features na Engenharia de Aplicações, IDEAS 2000, Cancún, México, 2000.
[74] Conradi, R., Fernstrom C. e Fuggetta, A.: Concepts for Evolving Software Process, Chapter 2, 9-31, em Finkelstein et all (65).
[75] Becker, U., Hamann, D., Verlage, M.: Descriptive Modeling of Software Processes, IESI-Report No. 045.97/E, Version 1, Fraunhofer IESI, Dec. 31, 1997.
[76] Olson, T. G. et all.: A Software Process Framework for the SEI Capability Maturity Model; Software Engineering Institute, Carnegie Mellon University, CMU/SEI-94-HB-01; August 1994.
[77] Altova GmbH, http://www.xmlspy.com, v.3.5, 2001.
[78] Mowbray, T. J., and Malveau, R., Corba Design Patterns, John Wiley & Sons, 1997.
[79] Meszaros, G. and Doble, J.: A Pattern Language for Pattern Writing, http://hillside.net/patterns/Writing/pattern_index.html
[80] Johnson, R., Frameworks = (Components + Patterns), Communications of the ACM, Vol. 40, n. 2, October 1997.
[81] Zimmer, W., Relationships Between Design Patterns, Pattern Language of Program Design, Vol. 1, edited by Coplien and Schimdt, Addison-Wesley, 1995.
[82] Loucopoulos, P, Karakostas, V.: System Requirements Engineering, Mc Graw Hill, 1995.
163
[83] Kotonya, G., Sommerville, I.: Requirements Engineering, Process and Techniques, Wiley, 1998.
[84] Leffingwell, D. e Widrig, D.: Managing Software Requirements, a Unified Approach, edited by Addison-Wesley Longman, Inc., 2000.
[85] Bracket, J. W.: Software Requirements, SEI Curriculum Module SEI-CM-19-1.2, January, 1990.
[86] Sutcliffe, A., A conceptual Framework for Requirements Engineering, Requirements Engineering, 1:170-189, 1996
[87] Leite, J. C. S. P.: Engenharia de Requisitos, Notas de Aula, Departamento de Informática, PUC-Rio, 1995.
[88] Alcázar, H.G., Monzón, A., A Process Framework for Requirements Analysis and Specification, Requirementes Engineering 2000, IEEE Software, pp 27-35, 2000.
[89] Crespo, S., Lucena, C. J. P., Staa, A., FrameConstructor: uma Ferramenta para Suporte à Construção Sistemática de Frameworks, Monografias em Ciência da Computação no. 42/48, Departamento de Informática, PUC-Rio, 1998.
[90] Curtis, B.:, The Global Pursuit of Process Maturity, IEEE Software, July/ August, pp 76-78, 2000.
[91] Welty, C., Ferruci, D.: A Formal Ontology for Re-Use of Architecture-Level Software Documents, Proceedings of the 14th IEEE International Conference on Automated Software Engineering, Cocoa Beach, Florida, October, 1999.
[92] IDS Scheer, Manual do Curso de Operação ARIS, São Paulo, Setembro 2000.
[93] Leite, J.C.S.P., Franco, A.P.M., A Strategy for Conceptual Model Acquisition, Proceedings of the IEEE International Symposium on Requirements Engineering, IEEE Computer Society Press, Pg. 243-246, San Diego, 1993.
[94] Fiorini, S. T., Leite, J. C. S. P., Lucena, C. P.: Process Reuse Architecture, The 13th Conference on Advanced Information Systems Engineering – CAiSE 2001, LNCS-series, Interlaken, Switzerland, Junho, 2001.
[95] ABNT: NBR ISO/IEC 9000, Sistema de Gestão da Qualidade – Fundamentos e Vocabulário, Dezembro 2000.
[96] Weber, K.C., Rocha, A. R. C. e Nascimento, C. J.: Qualidade e Produtividade em Software, 4ª edição, Makron Books, 2001.
[97] Fuggetta, A.: Software Process: a roadmap, The Future of Software Engineering, ACM Press, June 2000
[98] Cattaneo, F, Fuggetta, A., Scuito, D.: Pursuing Coherence in Software Process Assessment and Improvement, Software Process: Improvement and Practice, Volume 6, Issue 1, 2001.
[99] Ambriola, V., Conradi R., Fuggetta, A.: Assessing process-centered software engineering environments, ACM Transactions on Software Engineering and Methodology, vol. 6, 1997.
[100] Cugola, G., Ghezzi, C.: Software process: a restrospective and path to the future, in Software Process – Improvement and Practice, vol 4, pp. 101-123, 1998.
164
[101] Fuggeta, A., Wolf, A.: Trends in Software Process, in Trends in Software, B. Khrisnamurthy, Ed. John Wiley, 1995.
[102] John Wiley & Sons, Ltd, Software Process: Improvement and Practice, Journal, http://www3.interscience.wiley.com/cgi-bin/jtoc?ID=15482, Online ISSN: 1099-1670
[103] Ett, W., Kellner, M., Over, J., Phillips, D.: Defining Manually Enactable Processes Using the Process Definition Information Organizer Templates, Eletronic Systems Center, Defense Technical Information Center, Cameron Station, Alexandria, March 6, 1995.
[104] Over, J., Kellner, M.: Fundamentals of Software Process Definition, Tutorial in SEPG National Meeting, Dallas, TX, Software Engineering Institute, Pittsburgh, PA, 1994.
[105] Bechtold, R., Brackett, J.: Process Definition and Modeling Guidebook - Volume 1: Concepts and Principles of MPDM, Version 002.00.02, Software Productivity Consortium, Herndon, March, 1994.
[106] CapGeminin Sogeti: ProcessWeaver User’s Manual and Reference Manual , Version PW1.2, Grenoble, France, 1992.
[107] Hewllett-Packard: Introduction to SynerVision: Models of Use, HP Document B3261-90002, Draft May, 1993.
[108] Ett, W., Terrel, J., Lineham, A.: Software Process Management System User’s Guide for IBM RISC System/6000, Version 1.0 Renamed Process Engineering and Analysis Kernel System (PEAKS), Eletronic Systems Center, IBM Federal Systems Company, Gaithersburg, July, 1993.
[109] Leite, J. C. S. P., Fiorini, S. T., Durán, A., Bernárdez, B., Díaz, S., Pelozo, E. I.: Requirements Processes: An Experience Report (submetido ao WER´2001 e futuro Relatório Técnico do Departamento de Informática da PUC-Rio), 2001.
165
Anexos A – DTDs e Documentos XML
Para um melhor entendimento das DTDs – Definição do Tipo de Documento – descreve-
se como são realizadas as declarações da gramática. Também, para acompanhar as DTDs
descritas neste Anexo, consulte paralelamente o esquema gráfico dos elementos da
linguagem de cada tipo de processo, definido no Capítulo 4. Os elementos descritos no
Capítulo 4 estão sombreados em cada DTD. Os exemplos XML têm a finalidade
ilustrativa , portanto não contemplam todos os elementos.
DECLARAÇÕES
Para cada tipo de processo, que são documentos XML, foi definida uma linguagem. Cada
linguagem está formalizada na DTD – Definição do Tipo de Documento (gramática),
através de declarações. Após esta introdução da meta linguagem encontram-se as DTDs
completas dos diferentes tipos de processos. As DTDs mostram em detalhes a
especificação dos elementos apresentados, nas seções anteriores. Como as DTDs foram
geradas com o auxílio da ferramenta XML SPY, seus elementos encontram-se em ordem
alfabética. Portanto, para tornar mais clara a leitura, sombrou-se os elementos pai da
gramática ficando mais evidente a estrutura dos documentos. Por exemplo, para o process
standard sobreamos o Standard, StdSecao, SecSubSecao, SubScItem, StdEntrada,
StdSaida. Exemplos de documentos XML também são apresentados para os tipos de
processos. O conteúdo foi truncado, pois o objetivo é mostrar a estrutura e apresentação.
8.1.1 DEFINIÇÃO DO TIPO DE DOCUMENTO - DOCTYPE
Para definir um determinado tipo de documento XML, por exemplo, um cadastro ou um
usual process, é necessário definir qual é a estrutura e restrições na estrutura do
documento. Estas definições ficam na DTD – Document Type Definition (Definição do
Tipo de Documento) e são reconhecidas pelo processador XML através da declaração
DOCTYPE. A DTD pode ser interna ou externa. Na DTD interna, a definição do
documento está armazenada juntamente com o conteúdo do documento. Na DTD externa,
166
dentro do documento que possui conteúdo existe uma referência para outro arquivo que
contém a definição (DTD).
8.1.2 DECLARAÇÃO DO TIPO DE ELEMENTO - !ELEMENT
Como descrito, cada documento XML contém um ou mais elementos. A declaração é da
seguinte forma:
<!ELEMENT nome_elemento conteúdo>
Um elemento possui um conteúdo. Este conteúdo pode ser:
§ EMPTY: vazio
§ ANY: qualquer conteúdo – quando você ainda não decidiu o conteúdo do elemento.
§ Elemento Filho (children element): é um elemento que está contido em outro, ou seja,
o conteúdo de um elemento é outro elemento ou vários elementos. O elemento que
contém outros é chamado pai e os elementos contidos são os elementos filhos.
§ Combinado (mixed content): usado para declarar elementos que contém uma mistura
de elementos filho e texto (#PCDATA).
Elementos Filho
Para declarar um Elemento em que o conteúdo seja outros elementos deve-se seguir a
seguinte declaração:
<!ELEMENT nome_elemento_pai (nome_elem_filho1, nome_elem_filho2, ....)
<!ELEMENT nome_elem_filho1 conteúdo>
<!ELEMENT nome_elem_filho2 conteúdo>
....
Percebe-se que cada elemento filho precisa ser declarado em separado, por exemplo
“nome_elem_filho1”.
Ocorrência e escolha dos elementos filho
Quando se desejar definir a ocorrência de um elemento filho utilizam-se os seguintes
operadores ao final dele:
(?) – para indicar que o elemento é opcional
(+) – para indicar que o elemento deve ocorrer uma ou mais vezes
167
(*) – para indicar que o elemento deve ocorrer zero ou mais vezes
Ex.:
<!ELEMENT nome_elemento_pai (nome_elem_filho1*, nome_elem_filho2, ....)
A escolha entre elementos filhos é definida pelo separador dos elementos na sua
declaração. O separador “ | ” indica que pode-se escolher um dos elementos da lista. A
vírgula , como separador na lista, indica a ordem dos elementos.
Ex.:
<!ELEMENT nome_elemento_pai (nome_elem_filho1, (nome_elem_filho2 |
nome_elem_filho3) )
8.1.3 DECLARAÇÕES DE ATRIBUTOS – ATTLIST
Atributos são informações adicionais associadas com um tipo de elemento. As
declarações da lista de atributos (ATTLIST) identificam quais tipos de elementos podem
ter atributos, que tipos de atributos eles podem ter, e qual o valor default que podem ter, e
precisam estar definidos na DTD. Atributos só podem aparecer em start tags ou em empty
tags.
A declaração é da seguinte forma:
<!ATTLIST nome_elemento nome_atributo tipo_atributo valor_ padrão >
....
No start tag do elemento a referência é a seguinte:
< nome_elemento nome_atributo = “valor_atributo”>
Ou seja, cada atributo é um par (nome=“valor”) presente no start-tag do elemento, logo
após o seu nome. Todos os valores de atributos devem estar entre aspas.
Os atributos possuem três partes: nome do atributo, tipo do atributo e valor padrão do
atributo.
168
DTD – USUAL PROCESS
<?xml version="1.0" encoding="UTF-8"?>
<!-- edited with XML Spy v3.5 beta 2 build Dec 1 2000 (http://www.xmlspy.com) by Soeli Fiorini (PUC-Rio) -->
<!--DTD generated by XML Spy v3.5 beta 2 build Dec 1 2000 (http://www.xmlspy.com)-->
<!ELEMENT AtvAtividadeDetalhada (AtvDtNome, AtvDtDescricao, AtvDtPreCondicao?, AtvDtEntrada, AtvDtSaida,
AtvPredecessor?, AtvDtPosCondicao?, AtvDtRestricao?, AtvRspNome, AtvMetodoTecnica?, AtvFerramenta?)>
<!ELEMENT ArtDescricao (#PCDATA)>
<!ELEMENT AtvDtAcao (#PCDATA)>
<!ELEMENT AtvDtEntrada EMPTY>
<!ATTLIST AtvDtEntrada
Artefato IDREFS #REQUIRED
>
<!ELEMENT AtvDtDescricao (#PCDATA)>
<!ELEMENT AtvDtNome (AtvDtAcao, AtvDtSinonimo, AtvDtObjeto)>
<!ELEMENT AtvDtPosCondicao (#PCDATA)>
<!ELEMENT AtvDtPreCondicao (#PCDATA)>
<!ELEMENT AtvDtObjeto (#PCDATA)>
<!ELEMENT AtvDtRestricao (#PCDATA)>
<!ELEMENT AtvDtSaida EMPTY>
<!ATTLIST AtvDtSaida
Artefato IDREFS #REQUIRED
>
<!ELEMENT AtvDtSinonimo (#PCDATA)>
<!ELEMENT AtvFerramenta EMPTY>
<!ATTLIST AtvFerramenta
Ferramenta IDREFS #IMPLIED
>
<!ELEMENT AtvMetodoTecnica EMPTY>
<!ATTLIST AtvMetodoTecnica
MetodoTecnica IDREFS #IMPLIED
>
<!ELEMENT AtvPredecessor EMPTY>
<!ATTLIST AtvPredecessor
Processo IDREFS #IMPLIED
>
<!ELEMENT AtvRspNome EMPTY>
<!ATTLIST AtvRspNome
Funcao IDREFS #REQUIRED
>
169
<!ELEMENT BaseProcesso (BpProcesso+, BpConceito*, BpFuncao+, BpVerificacao*, BpMedicao*,
BpTreinamento*, BpMetodoTecnica*, BpFerramenta*, BpFormulario*, BpPolitica*, BpArtefato+)>
<!ELEMENT BpArtefato (ArtDescricao)>
<!ATTLIST BpArtefato
IDArtNome ID #REQUIRED
>
<!ELEMENT BpConceito (CncTipoTermo, CncDescricao)>
<!ATTLIST BpConceito
IDCncNomeTermo ID #REQUIRED
>
<!ELEMENT BpFerramenta (FrmDescricao)>
<!ATTLIST BpFerramenta
IDFrmNome ID #REQUIRED
>
<!ELEMENT BpFormulario (FrlArquivo, FrlFinalidade)>
<!ATTLIST BpFormulario
IDFrlNome ID #REQUIRED
>
<!ELEMENT BpFuncao (FncDescricao)>
<!ATTLIST BpFuncao
IDFncNome ID #REQUIRED
>
<!ELEMENT BpMetodoTecnica (MtdDescricao, MtdRestricao?, MtdProdutoGerado, MtdReferencia?)>
<!ATTLIST BpMetodoTecnica
IDMtdNome ID #REQUIRED
>
<!ELEMENT BpMedicao (MtrDescricao, MtrMetrica, MtrFormula?)>
<!ATTLIST BpMedicao
IDMtrNome ID #REQUIRED
>
<!ELEMENT BpPolitica (PltDescricao)>
<!ATTLIST BpPolitica
IDPltNome ID #REQUIRED
>
<!ELEMENT BpProcesso (PrcNome, PrcAutor, PrcClassificacao, PrcNatureza, PrcObjetivo, PrcDescricao,
PrcPreCondicao?, PrcPosCondicao?, PrcRepresentMacro, PrcRepresentDetalhada?, PrcConformidade,
PrcCaracteristica, PrcPolitica?, PrcConceito?, PrcFuncao, PrcVerificacao?, PrcMedicao?, PrcTreinamento?,
PrcMetodoTecnica?, PrcFerramenta?, PrcFormulario?, PrcEntrada, PrcSaida, PrcAtividadeMacro+)>
<!ATTLIST BpProcesso
IDProcesso ID #REQUIRED
>
170
<!ELEMENT BpTreinamento (TrnDescricao, TrnPublico)>
<!ATTLIST BpTreinamento
IDTrnNome ID #REQUIRED
>
<!ELEMENT BpVerificacao (VrfTipo, VrfDescricao, VrfFrequencia?, VrfQuemRealiza?)>
<!ATTLIST BpVerificacao
IDVrfNome ID #REQUIRED
>
<!ELEMENT CncDescricao (#PCDATA)>
<!ELEMENT CncTipoTermo EMPTY>
<!ATTLIST CncTipoTermo
TipoTermo (Negocio | Tecnico) #REQUIRED
>
<!ELEMENT CrcArea EMPTY>
<!ATTLIST CrcArea
TipoAreaEngSW (Engenharia_Requisitos | Design | Construcao | Teste | Implantacao | Generica)
#REQUIRED
>
<!ELEMENT CrcCiclodeVida EMPTY>
<!ATTLIST CrcCiclodeVida
TipoCicloVidaEngSW (Espiral | Cascata_Waterfall | Prototipacao) #REQUIRED
>
<!ELEMENT CrcConhecimentoRequerido EMPTY>
<!ATTLIST CrcConhecimentoRequerido
NivelConhecimento (Especialista | Alto | Medio | Baixo) #REQUIRED
>
<!ELEMENT CrcDuracaoProjeto EMPTY>
<!ATTLIST CrcDuracaoProjeto
DuracaoProjeto (1-60h | 61-120h | 121-180h | 181-260h | 261-350h | acima350h) #REQUIRED
>
<!ELEMENT CrcLocalizacaoEquipeUsuaria EMPTY>
<!ATTLIST CrcLocalizacaoEquipeUsuaria
TipoLocalizacaoEquipe (Local | Distribuida) #REQUIRED
>
<!ELEMENT CrcSistema EMPTY>
<!ATTLIST CrcSistema
TipoSistema (Web | OO | BI | Transacional) #REQUIRED
>
<!ELEMENT CrcTamanhoEquipe EMPTY>
<!ATTLIST CrcTamanhoEquipe
TamanhoEquipe (Pequena | Media | Grande) #REQUIRED
>
171
<!ELEMENT CrcTamanhoOrganizacao EMPTY>
<!ATTLIST CrcTamanhoOrganizacao
TamanhoOrganizacao (Pequena | Media | Grande) #REQUIRED
>
<!ELEMENT FncDescricao (#PCDATA)>
<!ELEMENT FrlArquivo (#PCDATA)>
<!ATTLIST FrlArquivo
IDFormulario CDATA #REQUIRED
>
<!ELEMENT FrlFinalidade (#PCDATA)>
<!ELEMENT FrmDescricao (#PCDATA)>
<!ELEMENT MtdComoSeUsa (#PCDATA)>
<!ELEMENT MtdDescricao (MtdOqueeh, MtdPorqueUtilizar?, MtdQdoSeAplica, MtdComoSeUsa)>
<!ELEMENT MtdOqueeh (#PCDATA)>
<!ELEMENT MtdPorqueUtilizar (#PCDATA)>
<!ELEMENT MtdProdutoGerado (#PCDATA)>
<!ELEMENT MtdQdoSeAplica (#PCDATA)>
<!ELEMENT MtdReferencia (#PCDATA)>
<!ELEMENT MtdRestricao (#PCDATA)>
<!ELEMENT MtrDescricao (#PCDATA)>
<!ELEMENT MtrFormula (#PCDATA)>
<!ELEMENT MtrMetrica (#PCDATA)>
<!ELEMENT PltDescricao (#PCDATA)>
<!ELEMENT PrcAtividadeMacro (AtvDtNome, AtvDtDescricao, AtvDtPreCondicao?, AtvDtEntrada, AtvDtSaida,
AtvPredecessor?, AtvDtPosCondicao?, AtvDtRestricao?, AtvRspNome, AtvMetodoTecnica?, AtvFerramenta?,
AtvAtividadeDetalhada*)>
<!ELEMENT PrcAutor (#PCDATA)>
<!ELEMENT PrcCaracteristica (CrcArea, CrcCiclodeVida?, CrcSistema?, CrcTamanhoOrganizacao?,
CrcDuracaoProjeto?, CrcTamanhoEquipe?, CrcConhecimentoRequerido?, CrcLocalizacaoEquipeUsuaria?)>
<!ELEMENT PrcClassificacao EMPTY>
<!ATTLIST PrcClassificacao
TipoProcesso (Fundamental | Apoio | Organizacional) #REQUIRED
>
<!ELEMENT PrcConceito EMPTY>
<!ATTLIST PrcConceito
Conceito IDREFS #REQUIRED
>
<!ELEMENT PrcConformidade EMPTY>
<!ATTLIST PrcConformidade
TipoConformidade (CMM | CMMI | ISOIEC9000_3 | ISOIEC_12207 | Nenhuma) #REQUIRED
>
<!ELEMENT PrcDescricao (#PCDATA)>
172
<!ELEMENT PrcEntrada EMPTY>
<!ATTLIST PrcEntrada
Artefato IDREFS #REQUIRED
>
<!ELEMENT PrcFerramenta EMPTY>
<!ATTLIST PrcFerramenta
Ferramenta IDREFS #IMPLIED
>
<!ELEMENT PrcFormulario EMPTY>
<!ATTLIST PrcFormulario
Formulario IDREFS #IMPLIED
>
<!ELEMENT PrcFuncao EMPTY>
<!ATTLIST PrcFuncao
Funcao IDREFS #REQUIRED
>
<!ELEMENT PrcMetodoTecnica EMPTY>
<!ATTLIST PrcMetodoTecnica
MetodoTecnica IDREFS #IMPLIED
>
<!ELEMENT PrcMedicao EMPTY>
<!ATTLIST PrcMedicao
Medicao IDREFS #IMPLIED
>
<!ELEMENT PrcNatureza EMPTY>
<!ATTLIST PrcNatureza
TipoNatureza (Projeto | Framework | Base) #REQUIRED
>
<!ELEMENT PrcNome (#PCDATA)>
<!ELEMENT PrcObjetivo (#PCDATA)>
<!ELEMENT PrcPolitica EMPTY>
<!ATTLIST PrcPolitica
Politica IDREFS #REQUIRED
>
<!ELEMENT PrcPosCondicao (#PCDATA)>
<!ELEMENT PrcPreCondicao (#PCDATA)>
<!ELEMENT PrcRepresentDetalhada (#PCDATA)>
<!ATTLIST PrcRepresentDetalhada
DtlFluxoControle CDATA #IMPLIED
>
<!ELEMENT PrcRepresentMacro (#PCDATA)>
<!ATTLIST PrcRepresentMacro
173
McrFluxoControle CDATA #IMPLIED
>
<!ELEMENT PrcSaida EMPTY>
<!ATTLIST PrcSaida
Artefato IDREFS #REQUIRED
>
<!ELEMENT PrcTreinamento EMPTY>
<!ATTLIST PrcTreinamento
Treinamento IDREFS #IMPLIED
>
<!ELEMENT PrcVerificacao EMPTY>
<!ATTLIST PrcVerificacao
Verificacao IDREFS #IMPLIED
>
<!ELEMENT TrnDescricao (#PCDATA)>
<!ELEMENT TrnPublico (#PCDATA)>
<!ELEMENT VrfDescricao (#PCDATA)>
<!ELEMENT VrfFrequencia (#PCDATA)>
<!ELEMENT VrfQuemRealiza (#PCDATA)>
<!ELEMENT VrfTipo EMPTY>
<!ATTLIST VrfTipo
TipoVerificacao CDATA #REQUIRED
>
174
DTD – PROCESS PATTERN
<?xml version="1.0" encoding="UTF-8"?>
<!-- edited with XML Spy v3.5 beta 2 build Dec 1 2000 (http://www.xmlspy.com) by Soeli Fiorini (PUC-Rio) -->
<!--DTD generated by XML Spy v3.5 beta 2 build Dec 1 2000 (http://www.xmlspy.com)-->
<!ELEMENT CmnCausa (#PCDATA)>
<!ELEMENT CmnClassificacao (#PCDATA)>
<!ATTLIST CmnClassificacao
TipoComunidade (Engenharia_Requisitos) #REQUIRED
>
<!ELEMENT CmnCntOnde (#PCDATA)>
<!ELEMENT CmnCntQuando (#PCDATA)>
<!ELEMENT CmnCntQuem (#PCDATA)>
<!ELEMENT CmnContexto (CmnCntOnde, CmnCntQuando, CmnCntQuem)>
<!ELEMENT CmnArtefato (ArtDescricao)>
<!ATTLIST CmnArtefato
IDArtNome ID #REQUIRED
>
<!ELEMENT CmnFinalidade (#PCDATA)>
<!ELEMENT CmnNome (#PCDATA)>
<!ELEMENT CmnOrigem (#PCDATA)>
<!ELEMENT CmnPalavrasChave (#PCDATA)>
<!ELEMENT CmnProblema (#PCDATA)>
<!ELEMENT CmnPtnFamilia (PtnFmIdentificacao, PtnFmContexto, PtnFmCausa, PtnFmControle?,
PtnFmSolucao, PtnFmPatternRelacionado?, PtnFmRepresentacao?)>
<!ELEMENT CmnPtnIndividuo (PtnIndIdentificacao, PtnIndContexto, PtnIndCausa, PtnIndControle?,
PtnIndSolucao, PtnIndPatternRelacionado?, PtnIndRepresentacao?)>
<!ELEMENT CmnRepresentacao (#PCDATA)>
<!ATTLIST CmnRepresentacao
CmnFluxoControle CDATA #IMPLIED
>
<!ELEMENT ArtDescricao (#PCDATA)>
<!ELEMENT FmCnrDescricao (#PCDATA)>
<!ELEMENT FmIdtPalavra_chave (#PCDATA)>
<!ELEMENT FmIdtProblema (#PCDATA)>
<!ATTLIST FmIdtProblema
TipoProblema (Analise_Dominio | Elicitacao_Requisitos | Analise_Requisitos | Especificacao_Requisitos |
Comunicacao_Requisitos | Validacao_Requisitos) #REQUIRED
>
<!ELEMENT FmPatternSimilar (#PCDATA)>
175
<!ELEMENT FmSlcAcao (#PCDATA)>
<!ELEMENT FmSlcComponente (FmSlcNome, FmSlcPre_Condicao?, FmSlcEntrada+, FmSlcRecomendacao,
FmSlcRestricao?, FmSlcSaida+, FmSlcPos_Condicao?, FmSlcUsaPattern?)>
<!ATTLIST FmSlcComponente
IDComponente ID #REQUIRED
>
<!ELEMENT FmSlcEntrada EMPTY>
<!ATTLIST FmSlcEntrada
Entrada IDREFS #REQUIRED
>
<!ELEMENT FmSlcNome (FmSlcAcao, FmSlcSinonimo, FmSlcObjeto)>
<!ELEMENT FmSlcObjeto (#PCDATA)>
<!ELEMENT FmSlcPos_Condicao (#PCDATA)>
<!ELEMENT FmSlcPre_Condicao (#PCDATA)>
<!ELEMENT FmSlcRecomendacao (#PCDATA)>
<!ELEMENT FmSlcRestricao (#PCDATA)>
<!ELEMENT FmSlcSaida EMPTY>
<!ATTLIST FmSlcSaida
Saida IDREFS #REQUIRED
>
<!ELEMENT FmSlcSinonimo (#PCDATA)>
<!ELEMENT FmSlcUsaPattern EMPTY>
<!ATTLIST FmSlcUsaPattern
PatternUsado IDREFS #IMPLIED
>
<!ELEMENT IndCnrDescricao (#PCDATA)>
<!ELEMENT IndIdtPalavra_chave (#PCDATA)>
<!ELEMENT IndIdtProblema (#PCDATA)>
<!ATTLIST IndIdtProblema
TipoProblema (Analise_Dominio | Elicitacao_Requisitos | Analise_Requisitos | Especificacao_Requisitos |
Comunicacao_Requisitos | Validacao_Requisitos) #REQUIRED
>
<!ELEMENT IndPatternSimilar (#PCDATA)>
<!ELEMENT IndSlcAcao (#PCDATA)>
<!ELEMENT IndSlcComponente (IndSlcNome, IndSlcPre_Condicao?, IndSlcEntrada+, IndSlcRecomendacao,
IndSlcRestricao?, IndSlcSaida+, IndSlcPos_Condicao?)>
<!ELEMENT IndSlcEntrada EMPTY>
<!ATTLIST IndSlcEntrada
Entrada IDREFS #REQUIRED
>
<!ELEMENT IndSlcNome (IndSlcAcao, IndSlcSinonimo, IndSlcObjeto)>
<!ATTLIST IndSlcNome
176
IDComponente ID #REQUIRED
>
<!ELEMENT IndSlcObjeto (#PCDATA)>
<!ELEMENT IndSlcPos_Condicao (#PCDATA)>
<!ELEMENT IndSlcPre_Condicao (#PCDATA)>
<!ELEMENT IndSlcRecomendacao (#PCDATA)>
<!ELEMENT IndSlcRestricao (#PCDATA)>
<!ELEMENT IndSlcSaida EMPTY>
<!ATTLIST IndSlcSaida
Saida IDREFS #REQUIRED
>
<!ELEMENT IndSlcSinonimo (#PCDATA)>
<!ELEMENT PatternSociety (PtnComunidade+)>
<!ELEMENT PtnComunidade (CmnNome, CmnPalavrasChave, CmnOrigem, CmnFinalidade, CmnClassificacao,
CmnProblema, CmnContexto, CmnCausa, CmnRepresentacao?, CmnArtefato+, CmnPtnFamilia+,
CmnPtnIndividuo+)>
<!ATTLIST PtnComunidade
IDCmnNome ID #REQUIRED
>
<!ELEMENT PtnFmCausa (#PCDATA)>
<!ELEMENT PtnFmContexto (#PCDATA)>
<!ELEMENT PtnFmControle (FmCnrDescricao?)>
<!ELEMENT PtnFmIdentificacao (FmIdtPalavra_chave, FmIdtProblema)>
<!ATTLIST PtnFmIdentificacao
IDFmIdtNome ID #REQUIRED
>
<!ELEMENT PtnFmPatternRelacionado (FmPatternSimilar?)>
<!ELEMENT PtnFmRepresentacao (#PCDATA)>
<!ATTLIST PtnFmRepresentacao
PtnFmFluxoControle CDATA #IMPLIED
>
<!ELEMENT PtnFmSolucao (FmSlcComponente+)>
<!ELEMENT PtnIndCausa (#PCDATA)>
<!ELEMENT PtnIndContexto (#PCDATA)>
<!ELEMENT PtnIndControle (IndCnrDescricao?)>
<!ELEMENT PtnIndIdentificacao (IndIdtPalavra_chave, IndIdtProblema)>
<!ATTLIST PtnIndIdentificacao
IDIndIdtNome ID #REQUIRED
>
<!ELEMENT PtnIndPatternRelacionado (IndPatternSimilar?)>
<!ELEMENT PtnIndRepresentacao (#PCDATA)>
<!ATTLIST PtnIndRepresentacao
177
PtnIndFluxoControle CDATA #IMPLIED
>
<!ELEMENT PtnIndSolucao (IndSlcComponente+)>
178
DTD – PROCESS STANDARD
<?xml version="1.0" encoding="UTF-8"?>
<!-- edited with XML Spy v3.5 beta 2 build Dec 1 2000 (http://www.xmlspy.com) by Soeli Fiorini (PUC-Rio) -->
<!--DTD generated by XML Spy v3.5 beta 2 build Dec 1 2000 (http://www.xmlspy.com)-->
<!ELEMENT BaseStandard (Standard*)>
<!ELEMENT CncDescricao (#PCDATA)>
<!ELEMENT CncNomeTermo (#PCDATA)>
<!ELEMENT CncTipoTermo EMPTY>
<!ATTLIST CncTipoTermo
TipoTermo (Negocio | Tecnico) #REQUIRED
>
<!ELEMENT FncDescricao (#PCDATA)>
<!ELEMENT FncNome (#PCDATA)>
<!ELEMENT ItmDescricao (#PCDATA)>
<!ELEMENT ItmEntrada EMPTY>
<!ATTLIST ItmEntrada
Entrada IDREFS #REQUIRED
>
<!ELEMENT ItmNome (NmAcao, NmSinonimo, NmObjeto)>
<!ELEMENT ItmPos_Condicao (#PCDATA)>
<!ELEMENT ItmPre_Condicao (#PCDATA)>
<!ELEMENT ItmReferencia (#PCDATA)>
<!ELEMENT ItmResponsavel EMPTY>
<!ATTLIST ItmResponsavel
Responsavel IDREF #REQUIRED
>
<!ELEMENT ItmRestricao (#PCDATA)>
<!ELEMENT ItmSaida EMPTY>
<!ATTLIST ItmSaida
Saida IDREFS #REQUIRED
>
<!ELEMENT NmAcao (#PCDATA)>
<!ELEMENT NmObjeto (#PCDATA)>
<!ELEMENT NmSinonimo (#PCDATA)>
<!ELEMENT ArtDescricao (#PCDATA)>
<!ELEMENT ArtNome (#PCDATA)>
<!ELEMENT SecDescricaoSecao (#PCDATA)>
<!ELEMENT SecNome (#PCDATA)>
179
<!ATTLIST SecNome
IDSc ID #REQUIRED
>
<!ELEMENT SecObjetivo (#PCDATA)>
<!ELEMENT SecReferencia (#PCDATA)>
<!ELEMENT SecSubSecao (SubScNome, SubScReferencia, SubScObjetivo, SubScDescricao,
SubScRepresentacao?, SubScTreinamento?, SubScVerificacao?, SubScMedicao?, SubScFerramenta?,
SubScItem+)>
<!ELEMENT Standard (StdNome, StdPalavraChave, StdObjetivo, StdAplicabilidade, StdTipo, StdDescricao,
StdAutor, StdVersao, StdRepresentacao?, StdOndeEncontrar?, StdAdaptacao?, StdArtefato+, StdConceito*,
StdFuncao+, StdSecao+)>
<!ELEMENT StdAdaptacao (#PCDATA)>
<!ELEMENT StdAplicabilidade (#PCDATA)>
<!ELEMENT StdAutor (#PCDATA)>
<!ELEMENT StdArtefato (ArtNome, ArtDescricao)>
<!ATTLIST StdArtefato
IDArtefato ID #REQUIRED
>
<!ELEMENT StdConceito (CncNomeTermo, CncTipoTermo, CncDescricao)>
<!ELEMENT StdDescricao (#PCDATA)>
<!ELEMENT StdFuncao (FncNome, FncDescricao)>
<!ELEMENT StdObjetivo (#PCDATA)>
<!ELEMENT StdNome (#PCDATA)>
<!ATTLIST StdNome
IDstandard ID #REQUIRED
>
<!ELEMENT StdOndeEncontrar (#PCDATA)>
<!ELEMENT StdPalavraChave (#PCDATA)>
<!ELEMENT StdSecao (SecNome, SecReferencia?, SecObjetivo, SecDescricaoSecao, SecSubSecao+)>
<!ELEMENT StdRepresentacao (#PCDATA)>
<!ATTLIST StdRepresentacao
StdFluxoControle CDATA #IMPLIED
>
<!ELEMENT StdTipo EMPTY>
<!ATTLIST StdTipo
TipoStandard (Norma | Modelo) #REQUIRED
>
<!ELEMENT StdVersao (#PCDATA)>
<!ELEMENT SubScDescricao (#PCDATA)>
<!ELEMENT SubScItem (ItmNome, ItmReferencia?, ItmPre_Condicao?, ItmEntrada+, ItmDescricao,
ItmRestricao?, ItmSaida+, ItmPos_Condicao?, ItmResponsavel)>
<!ELEMENT SubScNome (#PCDATA)>
180
<!ATTLIST SubScNome
IDSubSc ID #REQUIRED
>
<!ELEMENT SubScObjetivo (#PCDATA)>
<!ELEMENT SubScReferencia (#PCDATA)>
<!ELEMENT SubScRepresentacao (#PCDATA)>
<!ATTLIST SubScRepresentacao
SubScFluxoControle CDATA #IMPLIED
>
<!ELEMENT SubScTreinamento (#PCDATA)>
<!ELEMENT SubScVerificacao (#PCDATA)>
<!ELEMENT SubScMedicao (#PCDATA)>
<!ELEMENT SubScFerramenta (#PCDATA)>
181
DOCUMENTO XML – PROCESS STANDARD (EXEMPLO)
<!-- edited with XML Spy v3.5 beta 2 build Dec 1 2000 (http://www.xmlspy.com) by Soeli Fiorini (PUC-Rio) -->
<!DOCTYPE BaseStandard SYSTEM "C:\xml\Standard221200.dtd">
<BaseStandard>
<Standard>
<!--==================== PROCESS STANDARD CMM N2 ====================-->
<StdNome IDstandard="s2">CMM</StdNome>
<StdPalavraChave>processo, software, melhoria continua, processo de desenvolvimento, SEI,
qualidade</StdPalavraChave>
<StdObjetivo>O CMM fornece uma diretriz para a seleção de estratégias de melhoria de processos,
permitindo a determinação da capacitação dos processos correntes e a conseqüente identificação das questões
mais críticas para a melhoria de processo e qualidade de software. </StdObjetivo>
<StdAplicabilidade>Uma organização pode utilizar o CMM para duas finalidades: melhorar os processos
que utiliza para desenvolver e manter software e avaliar o risco de contratar um projeto de software de uma outra
organização </StdAplicabilidade>
<StdTipo TipoStandard="Modelo"/>
<StdDescricao>O CMM - Capability Maturity Model (Modelo d maturidade da Capacitação) - é uma
estrutura (framework) que descreve os principais elementos de um processo de software efetivo . O CMM
descreve os estágios através dos quais organizações de software evoluem quando elas definem, implementam,
medem, controlam e melhoram seus processos de software. Uma organização pode utilizar o CMM para duas
finalidades: a) Melhorar os processos que utiliza para desenvolver e manter software; b) Avaliar o risco de
contratar um projeto de software de uma outra organização. Desta forma, provê e descreve um caminho de
melhoria evolutiva a partir de um processo ad hoc para um processo maduro e altamente disciplinado. Este
caminho de melhoria é definido por cinco níveis de maturidade: Inicial, Repetitivo, Definido, Gerenciado e em
Otimizaçã</StdDescricao>
<StdAutor>Mark Paulk et. all - SEI</StdAutor>
<StdVersao>v1.1</StdVersao>
<StdRepresentacao StdFluxoControle="Mostra-se a estrutura geral do CMM e suas áreas-chave , em
cada nível, que são os processos. Uma visão mais detalhada é formecida na subseção e item.">
c:/standardCMM.ppt </StdRepresentacao>
<StdOndeEncontrar>www.sei.cmu.edu</StdOndeEncontrar>
<StdAdaptacao>O CMM deve ser adaptado de acodo com as caracteristicas da organizacao. O CMM nao
e um metodo, pois nao estabelece areas especificas a serem seguidas a risca. E um modelo que precisa ser
estudado, compreendido e adaptado as caractersticas de cada organização. O modelo não diz como implementar
determinadas práticas, apenas determina o que deve ser feito. Cabe a cada organização determinar como
desenvolver e manter software, de modo que os requisitos do CMM sejam sa-tisfeitos. O CMM também não é
uma descrição exaustiva do processo de software. No entanto, define um conjunto de prioridades para atacar
problemas de desenvol-vimento de software. É um modelo que auxilia na comunicação entre envolvidos com
atividades de engenharia de software na medida em que estabelece uma lingua-em comum de conceitos para
falar do processo de softw</StdAdaptacao>
182
<!--==================== ARTEFATOS ====================-->
<StdArtefato IDArtefato="a1">
<ArtNome>PoliticaOrgRequisitos</ArtNome>
<ArtDescricao>Diretrizes para a organização. O projeto segue uma política organizacional para
gerenciar os requisitos alocados. Refere-se ao Compromisso 1 da área-chave de gerência de requisitos (CMM
N2).</ArtDescricao>
</StdArtefato>
<StdArtefato IDArtefato="a3">
<ArtNome>Requisitos documentados</ArtNome>
<ArtDescricao>Ter os requisitos técnicos, não técnicos e critérios de aceitação documentados.
Geralmente estão registrados no documento de requisitos.</ArtDescricao>
</StdArtefato>
<StdArtefato IDArtefato="a4">
<ArtNome>Recursos_e_Fundos</ArtNome>
<ArtDescricao> Referem-se a ter pessoas com experiência no domínio da aplicação e em engenharia
de software, ferramentas de suporte às atividades de gerência de requisitos e financiamento
adequado</ArtDescricao>
</StdArtefato>
<StdArtefato IDArtefato="a5">
<ArtNome>Treinamento em gerência de requisitos</ArtNome>
<ArtDescricao>Cursos, palestras, ... em por exemplo, técnicas e métodos de elicitação, análise e
validação de requisitos, métodos, padrões e procedimentos usados no projeto para os membros do grupo de
engenharia de software e de outros grupos relacionados a software.</ArtDescricao>
</StdArtefato>
<StdArtefato IDArtefato="a6">
<ArtNome>Requisitos revistos e documentados de acordo com mudanças</ArtNome>
<ArtDescricao>Requisitos que passaram por alguma verificação. Após rever os requisitos devem ser
alterados de acordo com as mudanças solicitadas</ArtDescricao>
</StdArtefato>
<StdArtefato IDArtefato="a7">
<ArtNome>Solicitacoes de mudancas de requisitos</ArtNome>
<ArtDescricao>Pedido de uma mudança nos requisitos. Como os requisitos evoluem mudancas
(inclusao, alteracao ou excludao de requisitos ou mudancas nos compromissos) podem ser solicitadas a qualquer
momento.</ArtDescricao>
</StdArtefato>
<!--==================== CONCEITOS ====================-->
<StdConceito>
<CncNomeTermo>Requisito alocado<CncNomeTermo/>
<CncTipoTermo TipoTermo="Negocio"/>
<CncDescricao/> Subconjunto dos requisitos de sistema que serão implementados nos componentes
de software do sistema<CncDescricao/>
</StdConceito>
183
<!--==================== FUNCOES ====================-->
<StdFuncao>
<FncNome>GrupoEngSoftware</FncNome>
<FncDescricao>Grupo formado por gerentes e técnicos responsáveis pelas atividades de
desenvolvimento e manutenção de software de um projeto de software.</FncDescricao>
</StdFuncao>
<!--==================== SECAO NIVEL 2 DO CMM ====================-->
<StdSecao>
<SecNome IDSc="n2">Nivel 2</SecNome>
<SecReferencia> Nivel 2 (N2 ) do Modelo</SecReferencia>
<SecObjetivo>O objetivo e dar enfase em práticas gerenciais para obter um processo
disciplinado</SecObjetivo>
<SecDescricaoSecao>Estão estabelecidos processos básicos de gerência de projeto para planejar e
acompanhar custos, prazos e funcionalidades. Compromissos são firmados e gerenciados e sucessos podem ser
repetidos. O processo de nível 2 é caracterizado como disciplinado porque o planejamento e o acompanhamento
do projeto de software são estáveis, tornando possível repetir desenvolvimentos bem sucedidos. O processo do
projeto está sob controle efetivo de um sistema de gerenciamento de projetos, seguindo planos realistas,
baseados em de-sempenhos de projetos anteriores.O processo de nível 2 é caracterizado como disciplinado
porque o planejamento e o acompanhamento do projeto de software são estáveis, tornando possível repetir des-
envolvimentos bem sucedidos. O processo do projeto está sob controle efetivo de um sistema de gerenciamento
de projetos, seguindo planos realistas, baseados em de-sempenhos de projetos anteriores.O processo de nível 2
é caracterizado como disciplinado porque o planejamento e o acompanhamento do projeto de software são
estáveis, tornando possível repetir des-envolvimentos bem sucedidos. O processo do projeto está sob controle
efetivo de um sistema de gerenciamento de projetos, seguindo planos realistas, baseados em de-sempenhos de
projetos anteriores. O processo de nível 2 é caracterizado como disciplinado porque o planejamento e o
acompanhamento do projeto de software são estáveis, tornando possível repetir des-envolvimentos bem
sucedidos. O processo do projeto está sob controle efetivo de um sistema de gerenciamento de projetos,
seguindo planos realistas, baseados em desempenhos de projetos anteriores.</SecDescricaoSecao>
<!--=========== SUBSECAO DO NIVEL 2 - GERENCIAR REQUISITOS ===============-->
<SecSubSecao>
<SubScNome IDSubSc="c21">Gerenciar requisitos</SubScNome>
<SubScReferencia>Área-chave (KPA) de Gerência de Requisitos (GR) do
Modelo</SubScReferencia>
<SubScObjetivo>A Gerência de Requisitos tem por finalidade estabelecer e manter um acordo
com o cliente com relação aos requisitos a serem observados no projeto de software. </SubScObjetivo>
<SubScDescricao>A análise e a alocação dos requisitos de sistema ao software, hardware, ou a
outros componentes do sistema, pode ser feita por um grupo externo ao grupo de engenha-ria de software (por
exemplo, o grupo de engenharia de sistemas). Porém, este grupo detém a responsabilidade de associar os
requisitos ao projeto do software. A análise e a alocação também são pré-requisitos para o trabalho do grupo de
engenharia de software. Com respeito às restrições do projeto, o grupo de engenharia de software toma passos
apropriados para garantir que os requisitos alocados sejam documenta-dos e controlados.Os requisitos alocados
incluem: requisitos técnicos, requisitos não-técnicos e critérios de aceit</SubScDescricao>
184
<SubScRepresentacao SubScFluxoControle="o standard nao define a ordem das
atividades.">c:/figuraCMM_N2_GR</SubScRepresentacao>
<SubScTreinamento>Técnicas e métodos de obtenção (elicitação), análise e validação de
requisitos; Domínio da aplicação do sistema a ser desenvolvido; Métodos, padrões e procedimentos usados pelo
projeto.</SubScTreinamento>
<SubScVerificacao>A gerência sênior revisa, periodicamente, todas as atividades de gerência dos
requisitos alocado (Verificacao 1 do CMM); O gerente de projeto revisa, periodicamente e quando da ocorrência
de eventos, todas as atividades de gerência dos requisitos alocados (Verificacao 2 do CMM) e O grupo de
garantia de qualidade de software revisa e/ou audita as atividades e artefatos utilizados para gerenciar os
requisitos alocados, reportando seus resultados (Verificacao 3 do CMM)</SubScVerificacao>
<SubScMedicao>Definir e utilizar medições que determinem o estado das atividades de gerência
dos requisitos alocados (Medicao 1)</SubScMedicao>
<SubScFerramenta>Ferramentas para o registro e a análise de requisitos; Planilhas eletrônicas;
Ferramentas para a gerência de configuração; Ferramentas para a rastreabilidade de requisitos; Ferramentas
para o gerenciamento de textos.</SubScFerramenta>
<!--==================== ITEM DE GERENCIAR REQUISITOS - REVISAR REQUISITOS
====================-->
<SubScItem>
<ItmNome>
<NmAcao>Revisar</NmAcao>
<NmSinonimo>rever</NmSinonimo>
<NmObjeto>Requisitos de Sistema</NmObjeto>
</ItmNome>
<ItmReferencia>Atividade 1 de Gerência de Requisitos</ItmReferencia>
<ItmPre_Condicao>Ter as responsabilidades estabelecidas para analisar e alocar os
requisitos (habilitação 1 do CMM)</ItmPre_Condicao>
<ItmEntrada Entrada="a1 a3"/>
<ItmDescricao>Identificar, por exemplo, se algum requisito esta ausente, se os requisitos
podem ser implementados, se estao bem declarados, consistentes uns com os outros, se são testaveis e
implementaveis. Documentar as alteracoes necessária e negociar os compromissos resultantes com os grupos
envolvidos e os gerentes de software.</ItmDescricao>
<ItmRestricao>Antes de incorpora-los ao projeto de software</ItmRestricao>
<ItmSaida Saida="a4"/>
<ItmPos_Condicao>Usar os requisitos como base para o desenvolvimento do software
(planos, artefatos e atividades) - Atividade 2 do CMM</ItmPos_Condicao>
<ItmResponsavel>GrupoEngSoftware</ItmResponsavel>
</SubScItem>
<!--==== ITEM DE GERENCIAR REQUISITOS - CONTROLAR ALTERACOES NOS
REQUISITOS ====================-->
<SubScItem>
<ItmNome>
<NmAcao>Controlar</NmAcao>
185
<NmSinonimo>rever, gerenciar</NmSinonimo>
<NmObjeto>alterações nos requisitos</NmObjeto>
</ItmNome>
<ItmReferencia>Atividade 3 da Gerência de Requisitos</ItmReferencia>
<ItmPre_Condicao>Ter as responsabilidades estabelecidas para analisar e alocar os
requisitos (habilitação 1)</ItmPre_Condicao>
<ItmEntrada Entrada="a7"/>
<ItmDescricao>Revisar as alterações nos requisitos alocados e incorporá-las ao projeto de
software (atividade 3). · O impacto nos compromissos existentes é avaliado e mudanças são negociadas quando
apropriado, as alterações que precisam ser feitas nos planos de software, artefatos e atividades resultantes das
alterações dos requisitos sao controladas (identificadas, avalidadas, documentadas ...).</ItmDescricao>
<ItmRestricao>-</ItmRestricao>
<ItmSaida Saida="a6"/>
<ItmPos_Condicao>Usar os requisitos alocadados (Verificacao 2
doCMM)</ItmPos_Condicao>
<ItmResponsavel>GrupoEngSoftware</ItmResponsavel>
</SubScItem>
</SecSubSecao>
</StdSecao>
</Standard>
</BaseStandard>
186
DOCUMENTO XML – USUAL PROCESS (EXEMPLO)
<?xml version="1.0"?>
<!-- edited with XML Spy v3.5 beta 2 build Dec 1 2000 (http://www.xmlspy.com) by Soeli Fiorini (PUC-Rio) -->
<BaseProcesso>
<!-- ============= Inicio Elemento Processo========= -->
<BpProcesso IDProcesso=":p01">
<PrcNome>PROCESSO DE ENGENHARIA DE REQUISITOS</PrcNome>
<PrcAutor>Pericles Loucopoulos e Vassilios Karakostas</PrcAutor>
<PrcClassificacao TipoProcesso="Fundamental"/>
<PrcNatureza TipoNatureza="Base"/>
<PrcObjetivo>Entender o problema, descrevê-lo formalmente e obter um acordo com respeito a natureza
do problema.</PrcObjetivo>
<PrcDescricao>Engenharia de requisitos é a atividade que transforma as necessidades e desejos do
cliente e potencial usuários de sistemas computadorizados, geralmente incompletos, e expresso em termos
informais, dentro de especificações mais consistentes, precisas e completas. É um processo crucial porque erros
cometidos nas fases iniciais de especificação e percebidos só após a implementação são caros para corrigir. É
uma atividade social delicada, pois requer envolvimento constante dos stakeholders e designers do sistema (que
possuem diferentes conhecimentos). Engenharia de requisitos é o processo que tenta descobrir, capturar, e
documentar os requisitos de muitos e diferentes stakeholders. A saída deste processo geralmente é uma "lista de
desejos" inofrmal, ao invés de ser uma especificação suficientemente formal para ser analisada e acordada pelos
stakeholders dos requisitos e desenvolvedor</PrcDescricao>
<PrcPreCondicao>Inicia depois de todos os limites e condições de desenvolvimento terem sido
estabelecidos para o projeto de software.</PrcPreCondicao>
<PrcPosCondicao>Ter obtido um acordo com respeito a que requisitos serão contemplados no
software.<PrcPosCondicao/>
<PrcRepresentMacro McrFluxoControle="Elicitação ocorre em paralelo com especificação e validação. A
especificação é o processo central podendo necessitar novas elicitações ou realizar a validação parcial ou total.
Validação está presente em todos os estágios da eng. requisitos.">c:/figs/loucopoulos.ppt</PrcRepresentMacro>
<PrcConformidade TipoConformidade="Nenhuma"/>
<PrcCaracteristica>
<CrcArea TipoAreaEngSW="Engenharia_Requisitos"/>
</PrcCaracteristica>
<PrcConceito Conceito="Engenharia_Requisitos"/>
<PrcFuncao IDREFFuncao="Engenheiro_Requisitos"/>
<PrcMetodoTecnica IDREFMetodoTecnica="Etnografia"/>
<PrcEntrada Artefato="Fonte_Requisitos Dados_Inicio_Projeto"/>
<PrcSaida Artefato="Modelo_Conceitual "/>
<!-- ============= Inicio Elemento AtividadeMacro ========= -->
<PrcAtividadeMacro>
<AtvDtNome>
187
<AtvNmAcao>ELICITAR </AtvNmAcao>
<AtvNmSinomino>obter, extrair</AtvNmSinomino>
<AtvNmObjeto>REQUISITOS</AtvNmObjeto>
</AtvDtNome>
<AtvDtDescricao>Tem como objetivo adquirir (elicitar) todo o conhecimento relevante a cerca de
algum problema do domínio e tornar-se um especialista no domínio, para produzir um modelo de requisitos. Isto
implica que a elicitação de requisitos está toda relacionada com o entendimento de algum domínio de problema
particular. </AtvDtDescricao>
<AtvDtPreCondicao>Inicia depois de todos os limites e condições de desenvolvimento terem sido
estabelecidos para o projeto de software.</AtvDtPreCondicao>
<AtvDtEntrada Artefato="Fonte_Requisitos"/>
<AtvDtSaida Artefato="Modelo_Conceitual"/>
<AtvPredecessor Processo=""/>
<AtvDtPosCondicao>Ter obtido um conjunto satisfatório de requisitos</AtvDtPosCondicao>
<AtvDtRestricao/>
<AtvRspNome Funcao="Engenheiro_Requisitos"/>
<AtvMetodoTecnica MetodoTecnica="Etnografia"/>
<!-- ============= Inicio Elemento AtividadeDetalhada ====== -->
<AtividadeDetalhada>
<AtvDtNome>
<AtvNmAcao>Identificar</AtvNmAcao>
<AtvNmSinomino>reconhecer</AtvNmSinomino>
<AtvNmObjeto>fontes de requisitos</AtvNmObjeto>
</AtvDtNome>
<AtvDtDescricao>Geralmente, problemas relacionados com software são complexos e estão
distribuídos entre várias pessoas, lugares e fontes, bem como o conhecimento está disponível em uma variedade
de notações (linguagem natural, modelos matemáticos, ...). Estas fontes devem ser
identificadas.</AtvDtDescricao>
<AtvDtEntrada Artefato="Dados_Inicio_Projeto"/>
<AtvDtSaida Artefato="Fonte_Requisitos"/>
<AtvRspNome Funcao="Engenheiro_Requisitos"/>
</AtividadeDetalhada>
<!-- ============= Inicio Elemento AtividadeDetalhada ====== -->
<AtividadeDetalhada>
<AtvDtNome>
<AtvNmAcao>Adquirir</AtvNmAcao>
<AtvNmSinomino>obter</AtvNmSinomino>
<AtvNmObjeto>conhecimento</AtvNmObjeto>
</AtvDtNome>
<AtvDtDescricao>Buscar nas fontes identificadas o conhecimento relevante para entender o
problema*. A fonte mais óbvia é o especilaista no domínio da aplicação. Entretanto, a elicitação do conhecimento
das fontes, especialmente quando elas são humanas é difícil porque nem sempre o conhecimento está disponível
188
na forma que pode ser usado pelo engenheiro de requisitos (analista). Para diminuir as dificuldades utilize uma
combinação de técnicas. A representação do conhecimento nesta fase geralmente faz uso da linguagem
natural.</AtvDtDescricao>
<AtvDtPreCondicao>Ter identificado as fontes de requisitos</AtvDtPreCondicao>
<AtvDtEntrada Artefato="Fonte_Requisitos"/>
<AtvDtSaida Artefato="Modelo_Conceitual"/>
<AtvPredecessor Processo="Identificar fontes de requisitos"/>
<AtvRspNome Funcao="Engenheiro_Requisitos "/>
<AtvMetodoTecnica MetodoTecnica="Etnografia"/>
</AtividadeDetalhada>
<!-- ============= Inicio Elemento AtividadeDetalhada ====== -->
<AtividadeDetalhada>
<AtvDtNome>
<AtvNmAcao>Decidir </AtvNmAcao>
<AtvNmSinomino>determinar </AtvNmSinomino>
<AtvNmObjeto>a relevância do conhecimento </AtvNmObjeto>
</AtvDtNome>
<AtvDtDescricao>Decidir a relevância do conhecimento para o problema em questão. O modelo
conceitual deve ser refinado de acordo com a relevância do conhecimento, sendo descartadas as informações
que não tenham relevância para o problema.</AtvDtDescricao>
<AtvDtPreCondicao>Ter adquirido algum conhecimento</AtvDtPreCondicao>
<AtvDtEntrada Artefato="Modelo_Conceitual"/>
<AtvDtSaida Artefato="Modelo_Conceitual"/>
<AtvPredecessor Processo="Adquirir conhecimento"/>
<AtvRspNome Funcao="Engenheiro_Requisitos "/>
<AtvMetodoTecnica MetodoTecnica="AnaliseMetasObj"/>
</AtividadeDetalhada>
<!-- ============= Fim Elemento AtividadeDetalhada ====== -->
</PrcAtividadeMacro>
<!-- ============= Fim Elemento AtividadeMacro ====== -->
</BpProcesso>
<!-- ============= Fim do elemento BpProcesso ============= -->
<!-- ============= Incio Elemento Auxiliar: Conceito=========== -->
<BpConceito IDCncNomeTermo="Engenharia_Requisitos">
<CncTipoTermo TipoTermo="Tecnico"/>
<CncDescricao>É o processo sistemático de desenvolver requisitos através de um processo cooperativo
e iterativo de analisar o problema, documentar os resultados e verificar o entendimento obtido.</CncDescricao>
</BpConceito>
<BpConceito IDCncNomeTermo="RequisitoNaoFunc">
<CncTipoTermo TipoTermo="Tecnico"/>
<CncDescricao>referem-se as características que o sistema precisa possuir. Podem ser definidos como
restrições do sistema. Exemplo, custo, precisão, desempenho e segurança.</CncDescricao>
189
</BpConceito>
<BpConceito IDCncNomeTermo="RequisitoFuncional">
<CncTipoTermo TipoTermo="Tecnico"/>
<CncDescricao>Referem-se a maneira como o sistema se comporta ou responde.</CncDescricao>
</BpConceito>
<!-- ============= Fim Elemento Auxiliar: Conceito=========== -->
<!-- ============= Incio Elemento Auxiliar: Funcao=========== -->
<BpFuncao IDFncNome="Engenheiro_Requisitos">
<FncDescricao>Também conhecido como o analista de sistemas. Responsável pelas atividades de
engenharia de requisitos.</FncDescricao>
</BpFuncao>
<BpFuncao IDFncNome="Desenvolvedores_SW">
<FncDescricao>Desenvolvedores de software quem definem o comportamento funcional desejado d
artefatos de software e seus requisitos não funcionais.</FncDescricao>
<!-- ============= Fim Elemento Auxiliar: Funcao=========== -->
<!-- ============= Incio Elemento Auxiliar: MetodoTecnica=========== -->
<BpMetodoTecnica IDMtdNome="Etnografia">
<MtdDescricao>
<MtdOqueeh>Um método desenvolvido e utilizado por antropologistas para entender mecanismos
sociais em "sociedades primitivas". Entretanto, as mesmas práticas podem ser utilizadas dentro de organizações
para analisar as práticas de trabalho. Prefere a utilização de métodos baseados no comportamento de membros
do grupo de usuários, pois questiona a validade de métodos tradicionais tais como entrevistas e questionários.
Através destas observações, "etnometodologistas", procuram entender as categorias e métodos usados pelos
usuários tornar suas ações passíveis de entendimento por outras pessoas, ao invés de impor seus próprios
métodos e categorias junto aos usuários.</MtdOqueeh>
<MtdPorqueUtilizar>Propostas sócio-técnicas podem fornecer um importante suplemento para
técnicas de análise de requisitos (?) orientada tecnicamente, uma vez que elas fornecem informações importantes
a cerca do ambiente do usuário, isto é atividades, conceitos, e padrões de interações.</MtdPorqueUtilizar>
<MtdQdoSeAplica>Quando se quer um entendimento detalhado do sistema e do domínio da
aplicação; e quando se tem tempo para elicitar os requisitos*.</MtdQdoSeAplica>
<MtdComoSeUsa>De acordo com as propostas sócio-técnicas, elicitação não pode ser praticada num
nível de usuários individuais, isolado de seu ambiente e de suas interações com outros usuários. Como
conseqüência, requisitos tem significado apenas no contexto (tempo, lugar e situação) na qual eles foram
observados. </MtdComoSeUsa>
</MtdDescricao>
<MtdProdutoGerado/>Registros detalhados de observações<MtdProdutoGerado/>
<MtdReferencia>Sommerville et al., 1993</MtdReferencia>
</BpMetodoTecnica>
<!-- ============= Fim Elemento Auxiliar: MetodoTecnica=========== -->
<!-- ============= Inicio Elemento Auxiliar: Artefatos ========= -->
<BpArtefato IDArtNome="Modelo_Conceitual">
190
<ArtDescricao>Conhecimento obtido das fontes de requisitos. É uma sucessão de modelos mentais do
domínio do problema que irão se tornar mais elaborados à medida que aumentam o entendimento da análise do
domínio. </ArtDescricao>
</BpArtefato>
<BpArtefato IDArtNome="EspecificacaoRequis">
<ArtDescricao>O modelo de especificação de requisitos é um conjunto de modelos que correspondem à
diferentes visões do problema. Estes modelos são o modelo da organização, o modelo de requisitos funcionais e
o modelo de requisitos não-funcionais. Entretanto, alguns métodos não distinguem estes modelos por razões de
simplicidade e esforço.</ArtDescricao>
</BpArtefato>
<BpArtefato IDArtNome="Fonte_Requisitos">
<ArtDescricao>Fonte de conhecimento do domínio. Refere-se ao conhecimento de especialistas do
domímio; literatura a respeito do domínio; sistemas de software existentes no domínio; aplicações de software
similares em outros domínios;Padrões nacionais e internacionais, que restringem o desenvolvimento de software
no domínio, outros stakeholders na organização que hospedam o sistema de software</ArtDescricao>
</BpArtefato>
<BpArtefato IDArtNome="Dados_Inicio_Projeto">
<ArtDescricao>Informações iniciais a respeito do projeto a ser desenvolvido. Muitas vezes está em um
contrato ou em uma solicitação.</ArtDescricao>
</BpArtefato>
<!-- ============= Fim Elemento Auxiliar: Artefatos ========= -->
</BaseProcesso>
191
DOCUMENTO XML – PROCESS PATTERNS (EXEMPLO)
<!-- edited with XML Spy v3.0 (http://www.xmlspy.com) by Soeli Fiorini (Puc-Rio) -->
<!-- DOCTYPE Pattern SYSTEM "C:\xml\PatternSociety.dtd"-->
<PatternSociety>
<! =============== O Process Pattern Comunidade RAPPeL ================>
<PtnComunidade>
<CmnNome ID="1">RAPPeL: A Requirements-Analysis-Process Pattern Language for Object-Oriented
Development</CmnNome>
<CmnPalavrasChave>requisitos, orientação a objetos, pattern, </CmnPalavrasChave>
<CmnOrigem>Um estudo de caso na Knowledge Systems Corporation (KSC) - Bruce G. Whitenack,
Jr.</CmnOrigem>
<CmnFinalidade>Fornece uma direção e racional para guiar analistas, desenvolvedores e gerentes de
projeto em determinar e definir requisitos para aplicações de negócio (por exemplo, sistemas gerenciais de
informação, sistemas de suporte a decisão, workflow gerencial, cromograma, ...) que sejam desenvolvidos em um
ambiente orientado a objetos. Embora RAPPeL seja voltada para orientação a objetos, alguns patterns são
aplicáveis para análise de requisitos de software em geral. Em resumo as metas são (1) Guiar analistas e
desenvolvedores de produtos par aplicar apropriadamente um conjunto de métodos e técnicas, tal que possa
produzir um entendimento e análise mais completa do problema; (2) fornecer uma estrutura através do qual se
captura e define requisitos antes e durante o desenvolvimento orientado a objetos e através do qual um produto
de software proposto pode ser avaliado, projetado, construído e testado; e (3) ser capaz de ratrear o design do
sistema de volta até os objetivos do sistema e do negócio inici</CmnFinalidade>
<CmnClassificacao TipoComunidade = "Eng_Requisitos">Processo de Desenvolvimento -
Requisitos</CmnClassificacao>
<CmnProblema>Existe um problema crônico e sério em determinar se a quantia de tempo disponibilizada
para a engenharia de requisitos (análise de requisitos) é suficiente para desenvolver software com
sucesso.</CmnProblema>
<CmnContexto>
<CmnCntOnde>Na Knowledge Systems Corporation (KSC)</CmnCntOnde>
<CmnCntQuando>quando desejam desenvolver produtos OO (smalltalk) </CmnCntQuando>
<CmnCntQuem>Clientes </CmnCntQuem>
</CmnContexto>
<CmnCausa>As causas do problema sao ... </CmnCausa>
<CmnRepresentacao>c:/figura.ppt</CmnRepresentacao> <!-- ====Veja a figura no final desta tese == -->
<!-- ====== Início Artefato (so um como exemplo) =======-->
<CmnArtefato>
<ArtNome> Especificação dos requisitos </ArtNome>
<ArtDescricao>A especificacao é o detalhamnento ...</ArtDescricao>
</CmnArtefato>
<!-- ====== Fim Artefato =======-->
192
<!-- =============Início Process Pattern Familia Validacao Requisitos ====================-->
<! -- ==== RAPPeL tem um pattern família Construir sistemas certos que tem um pattern família que é o Validar
Requisitos – aqui apresentado. Veja a representação da comunidade RAPPeL no final desta tese ===== -->
<CmnPtnFamilia>
<PtnFmIdentificacao>
<FmIdtNome ID="99">Validacao Requisitos</FmIdtNome>
<FmIdtPalavra_chave>validação, caso de uso, prototipação</FmIdtPalavra_chave>
<FmIdtProblema TipoProblema="Validação de requisitos">Como verificar que o comportamento
especificado dos requisitos está correto e completo.</FmIdtProblema>
</PtnFmIdentificacao>
<PtnFmContexto>O contexto ... </PtnFmContexto>
<FmCntCausa>Durante o processo de engenharia de requisitos um número de diferentes clientes
precisam examinar e aprovar os requisitos. Requisitos variam em suas necessidades de especificação - alguns
requerem especificação formal enquanto outros podem ser prototipados (protótipos descartáveis). Validação é o
processo no qual se um produto tem ou faz o que se espera ou o que está especificado. Os clientes apropriados
precisam precisam ler, estudar e validar os requisitos contra o que eles esperam que o produto tenha ou faça.
Clientes podem "fazer o papel" de vários casos de uso (use cases) usando os objetos do domínio para ter a
sensação se o sistema está fazendo o que é esperado. No entanto, é difícil validar manualmente se um sistema é
consistente e completo. Isto é um processo humano sem validação automatizada</FmCntCausa>
<!-- ======Inicio Solucao do problema da Familia Validar Requisitos =======-->
<PtnFmSolucao>
<!-- ======Componente1 que forma a Solucao =======-->
<FmSlcComponente>
<FmSlcNome ID="991">
<FmSlcAcao>Conduzir</FmSlcAcao>
<FmSlcObjeto>reuniões de revisão</FmSlcObjeto>
</FmSlcNome>
<FmSlcPre_Condicao>xxx-</FmSlcPre_Condicao>
<FmSlcEntrada>Especificação dos requisitos</FmSlcEntrada>
<FmSlcRecomendacao>Tenha todas as partes interessadas lendo toda a especificação de
requisitos. Conduza reuniões de revisão em seções de especificação de requisitos. Tenha um secret;ario
anotando em uma Lista de Questões todas as questões que surjam na revisão.</FmSlcRecomendacao>
<FmSlcSaida>Lista de Questões</FmSlcSaida>
<FmSlcPos_Condicao>Tratar as questões levantadas na reunião, estabeleça um grupo de
arbitragem para reconciliar desentendimentos a respeito dos requisitos; continue a verificação dos requisitos
durante o desenvolvimento do sistema, através de cada iteração.</FmSlcPos_Condicao>
</FmSlcComponente>
<!-- ======Fim Componente1 que forma a Solucao =======-->
<!-- ======Inicio Componente2 que forma a Solucao =======-->
<FmSlcComponente>
<FmSlcNome ID="992">
<FmSlcAcao>Construir</FmSlcAcao>
193
<FmSlcObjeto>protótipo</FmSlcObjeto>
</FmSlcNome>
<FmSlcPre_Condicao> xxx</FmSlcPre_Condicao>
<FmSlcEntrada>Especificação dos requisitos</FmSlcEntrada>
<FmSlcRecomendacao>Construa protótipos, distribua-os aos clientes e revise-os com os
usuários. Conduza levantamentos (surveys) e estudos de utilidade (usability). Registre todas as questões
surgidas em uma Lista de Questões</FmSlcRecomendacao>
<FmSlcRestricao>vvv </FmSlcRestricao>
<FmSlcSaida>Lista de Questões</FmSlcSaida>
<FmSlcPos_Condicao>Tratar as questões levantadas na reunião, estabeleça um grupo de
arbitragem para reconciliar </FmSlcPos_Condicao>
<!-- ======Verifica-se, a seguir, que o componente referencia um pattern =======-->
<FmSlcUsaPattern>
<FmSlcPatternUsado IDREF="97">Protótipos</FmSlcPatternUsado>
<FmSlcNomeRelacao>construir protótipo</FmSlcNomeRelacao>
</FmSlcUsaPattern>
</FmSlcComponente>
<!-- ======Fim Componente2 que forma a Solucao =======-->
</PtnFmSolucao>
<!-- ======Fim Solucao Validar Requisitos =======-->
<PtnFmPatternRelacionado>
<FmPatternSimilar>wwwwww </FmPatternSimilar>
</PtnFmPatternRelacionado>
<PtnFmRepresentacao>Figura x</PtnFmRepresentacao>
</CmnPtnFamilia>
<!-- ======Fim Process Pattern Familia Validacao Requisitos =======-->
<!-- ====== Início Process Pattern Indivíduo Protótipos =======-->
<CmnPtnIndividuo>
<PtnIndIdentificacao>
<IndIdtNome ID="97">Protótipos</IndIdtNome>
<IndOutrosNomes>não definido</IndOutrosNomes>
<IndPalavra_chave>protótipo, elicitacao, capturar requisitos</IndPalavra_chave>
<IndProblema TipoProblema="elicitação de requisitos? ">Como realmente capturar e determinar
requisitos com protótipos? Você não está arriscando um design e desenvolvimento prematuro do sistema, com
código que não será passível de manutenção?</IndProblema>
</PtnIndIdentificacao>
<PtnIndContexto> Quando a situacao ....</PtnIndContexto>
<IndCausa>Todos os requisitos dificilmente podem ser capturados na especificação funcional inicial.
Quanto mais prototipacao, whiteboarding e avaliação são realizadas, haverá necessidade de modificar os
requisitos. O lado ruim da prototipação é que soluções podem ser simplificadas e o software pode não ter a
dimensão adequada e pode não ser tão bem projetado. Sem um rigor e disciplina um produto corre sérios riscos
194
de falhar quando características são continuamente adicionadas, e na medida que prototipação é realizada
mudanças de requisitos podem ser necessárias. Iterações entre prototipacao e modelagem de use-case acontece
na fase de análise de requisitos. Em adição, expectativas dos clientes têm que ser mantidas, pois eles estão
vendo uma simulação e não um produto</IndCausa>
<!-- ====== Início Solucao do probl do Indivíduo =======-->
<PtnIndSolucao>
<!-- ====== Início Componente 1 da Solucao - Construir protótipo de alta fidelidade =======-->
<IndSlcComponente>
<IndSlcNome>
<IndSlcAcao>Construir </IndSlcAcao>
<IndSlcObjeto>protótipo alta fidelidade</IndSlcObjeto>
</IndSlcNome>
<IndSlcPre_Condicao>o protótipo é descartável</IndSlcPre_Condicao>
<IndSlcEntrada>post-its, cartões, folhas de papel ou uma ferramenta</IndSlcEntrada>
<IndSlcRecomendacao>Se você tiver experiência e se tiver ferramenta então desenvolva
protótipos de alta-fidelidade, caso contrário faça-os no papel (baixa fidelidade). Trabalhe com o cliente, iteraja
entre o protótipo e a modelagem use-case. Protótipos precisam de maior envolvimento e use case fornecem o
mesmo rigor. Acrescente na documentacao do use-case a refererência para as versões do
prototótipo.</IndSlcRecomendacao>
<IndSlcRestricao>Você não deve gastar mais do que 10 por cento de seu tempo aprendendo
como utilizar a ferramenta; embora a ferramenta seja capaz de gerar código que possa ser útil para
desenvolvimento evolutivo, o protótipo tem ser construído com o intuito de se jogar fora</IndSlcRestricao>
<IndSlcSaida>protótipo de baixa ou alta fidelidade </IndSlcSaida>
</IndSlcComponente>
<!-- ====== Fim do Componente 1 da Solucao para o problema =======-->
<!-- ====== O componente 2 – Construir protótipos de baixa fidelidade não está sendo
apresentado ======= -->
</PtnIndSolucao>
<!-- ====== Fim da Solucao do problema =======-->
</CmnPtnIndividuo>
<!-- ====== Fim Process Pattern Indivíduo Protótipos =======-->
</PtnComunidade>
<!-- ====== Fim Comunidade RAPPeL =======-->
<!-- ====== Início Comunidade xx (poderia se ter outras comunidades) =======-->
<PtnComunidade>
<CmnNome ID="2"/>
<CmnPalavrasChave>requisitos, orientacao a objetos, </CmnPalavrasChave>
.......
</PatternSociety>
!-- ====== Fim da Sociedade =======-->
195
Anexo B – Questionário Inicial
PESQUISA - REUTILIZAÇÃO DE PROCESSOS
Identificação:
Nome: Virginia Kayse
1.Formação:
xárea de informática (ciência da computação , processamento de dados ...)
outra área 2.SuaEmpresa:
Federal Estadualx
Particular
pesquisa x
comercial outro
Nome da Empresa (se possível): Empresa Y
3.Sua função:
consultor gerente analista_de_sistemas
xanalista_de_processos designer programador
pesquisador professor outro: 4.Tempo na Profissão:
- de 5 anos x
+ de 5 anos 5.Sua empresa tem alguma certificação?
Não
Sim:
xISO CMM_N2 CMM_N3 Outra:
6.Sua empresa busca alguma certificação?
Não
Sim: ISO x
CMM_N2 CMM_N3 Outra: 7. Sua experência em definicao de processos (negócio e/ou engenharia de software):
não_tenho_experiência
já_defini_alguns_até_5
196
defini_vários_+_de_5
xsou um especialista
8.Você já definiu algum processo de engenharia de requisitos?
Não
Sim. Quanto tempo você gastou aproximadamente: 1- 60 h, 61-180h,
x181 - 360h, + 360h
9. Imagine que você tenha que definir um processo de engenharia de requisitos. Isto lhe
parece ser fácil ou difícil?
é/parece ser fácil
xé/ parece ser dífícil ....( escolha abaixo - multipla - os motivos)
pela falta de conhecimento em definição de processos
xpela falta de modelos para definição de processos
xpela complexidade do processo
xpela falta de conhecimento disponível, a respeito do processo
porque ele tem que estar em conformidade com alguma norma/modelo
Outros: 10.Quantas horas você levaria para definí-lo de forma completa (atividades, descrições,
representação, medições, verificações, descriçoes de técnicas/métodos, ...), incluindo sua
documentação?
não tenho a menor idéia
1 - 60 h
61 -180 h
x181 -360 h
+ 360 h 11. Você segue, atualmente, algum processo de engenharia de requisitos
Sim, segundo processo definido na organizacao
sim, mas informalmente
197
xNão Motivo: Não atuo no desenvolvimento de sistemas
12. Voce já seguiu algum processo de engenharia de requisitos
xSim, segundo processo definido na organizacao
sim, mas informalmente
Não 13. Você acha que existem processos de Engenharia de Requisitos disponíveis e de fácil
acesso, para serem reutilizados ou consultados?
xNão Sim
14. Voce já utilizou alguma ferramenta para reutilizacao de processos?
xNão Sim - qual?
15. Você é familiar com os conceitos de:
Patterns: x
Não Sim
Frameworks: x
Não Sim 16. Observações sobre o questionário ou sobre suas respostas:
Enviar
198
Anexo C – Questionário Final
PESQUISA FINAL – REUTILIZAÇÃO DE PROCESSOS
1. Nome: Virginia Kayser
2. Tamanho da instituição (área de informática):
( ) menos de 10 pessoas ( ) entre 11 e 50 pessoas (x ) entre 51 e 100 pessoas
( ) mais de 100 pessoas ( ) sem vínculo com instituição
3. O que você definiu (múltipla escolha):
(x ) um ou mais processos através da pesquisa livre- parcial
(x ) um ou mais processos na reutilização total
( ) um ou mais processo através do framework
( ) não foi possível fazer a definição – Motivos : _____________
4. Foi fácil entender a estrutura dos tipos de processos (process patterns, process standard e usual
process)?
ü Usual process: ( x) Sim ( )Razoavelmente Porque: ___ ( ) Não Porque: ___
ü Process pattern: ( ) Sim (x )Razoavelmente Porque: não era familiar ( ) Não Porque: ___
ü Process standard: (x ) Sim ( )Razoavelmente Porque: ___ ( ) Não Porque: ___
5. A forma como os tipos de processos foram organizados e estruturados auxiliou na pesquisa e
recuperação das informações?
ü Usual process: ( x) Sim ( )Razoavelmente Porque: ___ ( ) Não Porque: ___
ü Process pattern: (x ) Sim ( )Razoavelmente Porque: ___ ( ) Não Porque: ___
ü Process standard: (x ) Sim ( )Razoavelmente Porque: ___ ( ) Não Porque: ___
6. O fato dos três tipos de processos (standards, patterns e usual) estarem juntos contribuiu ou
facilita de alguma forma a definição dos processos?
(x ) Sim ( ) Razoavelmente Porque: _____
( ) Não Porque: ________ ( ) É indiferente
7. Foi mais fácil reutilizar através da pesquisa livre ou do framework?
( x) Pesquisa Livre ( ) Framework ( ) Para ambas foi fácil ( ) Para ambas foi difícil
8. Você definiria (ou definiu) um processo usando os process patterns e process standards?
(x ) Sim, usaria ambos ( ) Sim, mas só com process patterns
( ) Sim, mas só com process standards ( ) Não motivo ______________
9. Você utilizou os guia de reutilização do framework?
Sim __ Achei bom __Acho que pode melhorar ___Não gostei: motivo
( x ) Não Motivo: Não utilizei na reutilização, embora tenha acessado o framework e achado muito
interessante.
199
10. Você tem conhecimento razoável do (multipla escolha) :
(x ) CMM N2 ( ) ISO/IEC 12207 ( ) RAPPeL (pattern) ( ) não conheço nenhum deles
11. Quanto tempo você levou para definir um processo básico (apenas com a escolha das atividades
a serem reutilizadas)?
Num. Horas – Pesquisa Livre/ parcial: 12 h ( ) Não defini
Num. Horas – Pesquisa Livre/ total : ______ ( ) Não defini
Num. Horas – Pesquisa Framework : ______ ( ) Não defini
12. Quanto tempo você levou para definir um processo completo (com todas as informações do
processo) e qual foi o tipo de reutilização?
Num. Horas: 56 h Tipo reutilização: ( x) Livre parcial ( ) Framework ( x) processo total
( ) Não defini
13. A interface ou performance do ferramenta comprometeu a reutilização?
( ) Sim – interface ( ) Sim – performance ( ) Sim- ambas ( ) não
(x )outros problemas comprometeram – Foram: o acesso, às vezes estava fora o site ou a PUC
14. O que teve mais valor para você na reutilização (múltipla escolha)?
(x ) as descrições das atividades ( x) os elementos auxiliares (formulários, medições, artefatos,
conceitos, ...) ( ) os guias de reutilização ( )a forma como os process standards/ patterns foram
estruturados ( x) a linguagem de modelagem ( )outros: ____
15. Considerando a base de dados disponível, você considera que o nível de reutilização das
descrições e elementos do processo que obteve (para o melhor processo que você definiu) foi:
(x) Alto - conseguiu reutilizar muita informação, podendo definir processos bem razoáveis,
necessitando ou não de algumas adaptações/ definições
( ) Médio - conseguiu reutilizar algumas informações, podendo definir processos razoáveis,
necessitando de muitas adaptações
( ) Baixo (raramente foi possível reutilizar alguma informação e o processo que foi definido terá que
ser totalmente redefinido)
16. Como você classificaria (pontuação de 1 a 10) o uso desta proposta de reutilização de
processos nas organizações e empresas de consultoria?
0 ( ) inviável 1-3 ( ) pouco viável 4-6 ( ) viável com melhorias na ferramenta 7-9 (x ) viável com
poucas melhorias 10 ( ) completamente viável
Observações: A ferramenta foi bastante útil economizando muito tempo na definição. A geração da
documentação também ajuda muito.
200
Anexo D – Estudo de Caso da Empresa Y
Estudo de Caso
Processo de Engenharia de Requisitos Empresa Y
Processo de Engenharia de Requisitos
Página 2
CONTROLE DE MUDANÇA E VERSÃO
VERSÃO DATA MUDANÇA RESPONSÁVEL REVISOR
1.0 15/07/2000 Versão Inicial Soeli Fiorini e
Empresa Y
Equipe do Projeto X da Empresa Y
Processo de Engenharia de Requisitos
Página 3
Índice 1. PROCESSO ENGENHARIA DE REQUISITOS: ESTUDO DE CASO DA EMPRESA Y ........................ 4
2. ATIVIDADES ..................................................................................................................................... 7
A1 – Entender o Problema/ Escopo ........................................................................................................ 7 A.2 – Encontrar Atores ......................................................................................................................... 8 A.3 – Capturar Vocabulário Comum ....................................................................................................... 9 B1 – Definir atributos de Requisitos ..................................................................................................... 10 B.2 – Elicitar Requisições dos Stakeholders .......................................................................................... 11 B.3 – Complementar Documento Visão ................................................................................................ . 12 C.1 – Elaborar a Lista de Casos de Uso ............................................................................................... 13 C.2 – Revisar Requisitos Alocados ....................................................................................................... 14 D.1 – Elaborar modelo de casos de uso da iteração ............................................................................... 15 E.1 – Priorizar Casos de uso ............................................................................................................... 16 F.1 – Detalhar Casos de Uso ............................................................................................................... 18 F.2 – Modelar Interface do Usuário ..................................................................................................... 19 E.4 – Prototipar interface do usuário ................................................................................................... 20 G. 1 – Gerenciar Dependências entre Requisitos ................................ ................................................... 22 G.2 – Gerenciar mudanças nos requisitos ............................................................................................. 22
3. TABELAS AUXILIARES .................................................................................................................. 23
3.1. POLÍTICA ...................................................................................................................................... 23 3.2. CONCEITOS ................................................................................................................................... 23 3.3. FUNÇÕES ...................................................................................................................................... 24 3.4. MEDIÇÕES .................................................................................................................................... 26 3.5. TREINAMENTO .............................................................................................................................. 26 3.6. FERRAMENTAS .............................................................................................................................. 26 3.7. VERIFICAÇÕES .............................................................................................................................. 26 3.8. MÉTODOS/ TÉCNICAS ..................................................................................................................... 28 3.9. FORMULÁRIOS ............................................................................................................................... 31
Processo de Engenharia de Requisitos
Página 4
1. Processo Engenharia de Requisitos: Estudo de Caso da Empresa Y
Autor: Soeli Fiorini/ Empresa Y
Natureza: Projeto
Classificação: Processo Fundamental
Objetivo: Os objetivos deste processo são estabelecer um entendimento comum sobre o que o sistema deve fazer, através da análise do problema e da definição dos requisitos e, deve ser capaz de gerenciar a dependência dos requisitos e suas mudanças.
Descrição:
O processo de engenharia de requisitos apresentado tem como base o processo da Rational, visto que a empresa possui a ferramenta RequisitePro e utiliza a técnica de Casos de Uso.
O processo de engenharia de requisitos é composto pelos seguintes sub-processos:
DDeeff iinnii rr oo PPrroobblleemmaa .. O propósito deste sub-processo é obter uma visão-macro do sistema, a partir da interação com os Stakeholders.
A análise do problema é realizada com o objetivo de entender os problemas, as necessidades iniciais dos Stakeholders e propor uma solução em um alto nível. Neste momento é obtido um consenso entre o problema real a ser solucionado e quem são os Stakeholders do sistema.
Este sub-processo tem como principais objetivos:
§ Iniciar a elaboração do Documento de Visão (Documento de Requisitos) onde são registradas, em alto nível, os tópicos iniciais do Documento e o glossário de termos.
§ Obter consenso sobre o problema, funcionalidades macros e objetivos do sistema, delimitando no nível de negócio, suas fronteiras e restrições.
Este sub-processo deve ser revisto várias vezes na medida que as necessidades dos Stakeholders são entendidas mais claramente, as soluções de processo de negócio e as soluções técnicas também evoluem.
EEnntteennddee rr aass NNeecceessssiiddaaddeess ddooss SSttaakkeehhoollddeerrss A atividade principal deste sub-processo é eleger as necessidades dos Stakeholders e priorizá-las, possibilitando o refinamento do Documento de Visão . Os requisitos obtidos podem ser vistos como uma "lista de desejos" (wish list) que será usada como insumo primário para a definição da Lista dos Casos de Uso, do Modelo de Casos de Uso, e das Especificações Suplementares.
No Documento de Visão , os requisitos são expressos como funcionalidades-chave que o sistema deve possuir. Para cada funcionalidade deverão ser vinculados atributos, de modo a se poder controlar dependências.
No decorrer do desenvolvimento do Documento de Visão , o Engenheiro de Requisitos registra os atores, ou seja, os usuários e os demais sistemas que interagem com o sistema a ser desenvolvido.
O propósito deste sub-processo é:
§ Capturar e eleger informações dos Stakeholders do sistema
§ Complementar o documento de requisitos registrando as funcionalidades e requisitos não funcionais.
§ Definir os atributos que todos os requisitos terão que registrar, por exemplo, origem.
DDeeff iinnii rr oo ssiisstteemmaa Definir o sistema significa traduzir e organizar o entendimento das necessidades dos Stakeholders em uma descrição significativa, e mais detalhada do sistema a ser desenvolvido.
Os propósitos deste sub-processo são:
§ Unificar o conhecimento da equipe do projeto sobre entendimento do sistema;
§ Refinar a análise das solicitações dos Stakeholders;
§ Documentar mais formalmente os resultados, sob a forma de modelos.
Deverá ser dado foco na elaboração da Lista de Casos de Uso e a sua revisão.
DDeeff iinnii rr aa II tteerraaççããoo O propósito deste sub-processo é:
§ definir entradas para seleção dos requisitos que serão incluídos na iteração corrente;
Processo de Engenharia de Requisitos
Página 5
§ definir o conjunto de funcionalidades e Casos de Uso (ou cenários) que representam alguma funcionalidade central e significativa;
§ definir quais atributos de requisitos e traceability devem ser gerenciados.
GGeerreenncciiaa rr EEssccooppoo ddoo SSii sstteemmaa((II tteerraaççããoo)) O escopo de um projeto é definido pelo seu conjunto de requisitos alocados. Gerenciar o escopo do projeto para enquadrá-lo nos recursos disponíveis (tempo, pessoas e recursos financeiros) é a chave para gerenciar projetos com sucesso. Gerenciar escopo é uma atividade contínua que requer desenvolvimento incremental e iterativo, o qual quebra o escopo do projeto em peças menores e mais gerenciáveis.
O propósito deste sub-processo é:
§ descrever em detalhes o fluxo de eventos dos Casos de Uso;
§ detalhar as especificações suplementares;
§ modelar e prototipar a interface com o usuário.
O refinamento do sistema começa com os esboços dos Casos de Uso, a descrição breve dos atores e o entendimento do escopo do projeto, refletida nas funcionalidades priorizadas do Documento de Visão . Estas funcionalidades priorizadas devem contemplar corretamente os prazos e orçamentos.
RReeff iinnaa rr aa DDeeff iinnii ççããoo ddaa II tteerraaççããoo A definição detalhada do projeto do sistema deve ser feita de modo que os stakeholders possam entender e concordar com elas. É necessário cobrir não somente as funcionalidades, mas também compatibilidade com qualquer requisito regulatório e legal, usabilidade, comfiabilidade, performance, suportabilidade e mantenibilidade. É preciso despender esforço para que os documentos que descrevem o sistema sejam entendidos.
O propósito deste sub-processo é:
§ especificar os casos de uso;
§ modelar a interface do usuário;
§ prototipar interface do usuário
GGeerreenncciiaa rr MMuuddaannççaass ddee RReeqquuiissii ttooss As alterações nos requisitos impactam naturalmente os modelos produzidos, bem como os modelos de teste. As relações de traceability entre requisitos é a chave para entender o impacto das mudanças.
O propósito deste sub-processo é:
§ gerenciar a dependência entre requisitos, configurando apropriadamente os atributos dos requisitos e a traceability;
§ Gerenciar a mudança dos requisitos verificando o impacto e utilizando um processo de solicitação de mudanças.
Pre-condição: Ter recebido o ok de início do projeto e ter realizado o planejamento inicial.
Pos-condição: Ter revisto e aprovado os requisitos com os stakeholders e usuários e ter especificado os casos de teste.
Palavra-chave: requisito, rational, caso de uso (use case)
Representação Macro:
Processo de Engenharia de Requisitos
Página 6
A.1 - Entender o problema/
escopo
B.2- Elicitar requisitos
A.2 - Encontrar Atores
B.3 - Compl. doc. requisitos
A.3 - Capturar Vocabulário
Comum
Analisar o Problema
Definir o Problema
A
Entender as Necessidades do Stakeholder
Entender as Necessidades do Stakeholder
B
Definir o SistemaDefinir
o Sistema
C
Definir a Iteração
Definir a Iteração
D
Gerenciar o Escopo da
Iteração
Gerenciar o Escopo da
Iteração
ERefinar a
Definição daIteração
Refinar aDefinição da
Iteração
F
C.1 - Elaborar Lista de Casos
de uso
D.1 - ElaborarMod. Caso
de Uso IteraçãoE.1 - PriorizarCasos de Uso
F.1 - Especificar Casos de Uso
F.2 - Modelar Interface do
Usuário
F.3 - Prototipar Interface do
Usuário
Gerenciar Mudanças de
Requisitos
Gerenciar Requisitos
G G1 - Gerenciar Dependências
C.2 - Revisar requisitos
G2 - Gerenciar Mudanças de
Requisitos
B.1 - DefinirAtributos
de Requisitos
Fluxo de Controle: Embora as atividades estejam de forma sequencial (A-F) elas são interrelacionadas e às vezes são realizadas em conjunto ou paralelo. Loops também não estão representados. A atividade G é realizada em paralelo, durante todo o processo.
Representação Detalhada:
Eng
.Req
uisi
toSt
akeh
./use
rsD
esig
ner
Elicitar Requisitos
B2
Entender oProblema/
Escopo
A1 Complementar Documento
de Requisitos
B3
EncontrarAtores
A2
Definir Atributos dos
Requisitos
B1Capturar Vocabulário
Comum
A3
Elaborar a lista de Casos
C1
Revisar Requisitos
C2
Elaborar Mod. Caso de Uso Iteração
D1
Priorizar Casos de Uso
E1
Especificar Casos de Uso
F1
Prototipar Interface
do Usuário
F3Modelar Interface do usuário
F2
Há mais iterações previstas
Fim
Início
Sim Não de uso
Eng
. Req
uisi
ots/
Sta
keho
lder
s/ U
suár
ios
Eng
.Req
uisi
tos
Requisitos
Gerenciar
Requisitos
Gerenciar Mudanças
G1
G2
Fluxo de controle: Através da representação detalhada percebe-se o ciclo de vida espiral e o tratamento dos requisitos (agrupados nos use cases) através de iterações. As atividades de gerenciamento são paralelas e podem iniciar em qualquer ponto do fluxo, uma vez que se tenha
Processo de Engenharia de Requisitos
Página 7
definido e algum requisito, e no caso das mudanças a partir do momento que se tenha aprovado os requisitos.
Conformidade: -
Características:
Área: Engenharia de requisitos
Ciclo de vida: espiral
Tipo de sistema: Orientado a objetos
Tamanho da organização:100 pessoas
Duração do projeto:1 ano
Tamanho da equipe:12 pessoas
Conhecimento requerido: alto
Localização da equipe usuária: distribuída
2. Atividades
A. Definir o Problema DDeessccrr iiççããoo O objetivo é obter uma formulação clara e um entendimento e acordo sobre que problemas que devem ser solucionados, identificando os stakeholders, bem como definir as fronteiras e as principais funcionalidades e restrições do sistema. Deve ser elaborada uma descrição do sistema. O objetivo final é produzir um documento de visão (requisitos) para o projeto, que identifica uma visão alto nível do sistema a ser construído, do ponto de vista dos usuários e clientes. Ou seja, obtém-se um acordo das metas e características do sistema.
PPrréé--ccoonnddiiççããoo :: Ter recebido a sinalização de início do projeto.
PPóóss--ccoonnddiiççããoo:: Ter entendido o problema, escopo e principais funcionalidades macros do sistema.
EEnntt rraaddaass § Contrato para desenvolvimento/Manutenção de Software
SSaaííddaass § Documento de Visão, Glossário de Termos e Modelo de Casos de Uso
RReessppoonnssáávvee ll § Engenheiro de requisitos
MMééttooddooss ee TTééccnniiccaass § Entrevistas
§ Use Case
FFee rrrraammeennttaa § Requisite Pro (armazenar o documento de visão e glossário e registrar atores)
A1 – Entender o Problema/ Escopo
DDeessccrr iiççããoo Para se ter uma visão do sistema deve-se realizar os seguintes passos: acordar os problemas sendo resolvidos; identificar os stakeholders; definir os limites do sistema; identificar as restrições a serem impostas ao sistema; formular a declaração do problema; definir as características do sistema e avaliar os resultados.
Aplicar a seguinte sequência de perguntas, para identificar Stakeholders :
1. Quem são os usuários do sistema?
2. Quem é o comprador (econômico) do sistema?
3. Quem mais será afetado pelas saídas ou resultados do sistema?
4. Quem irá avaliar e aceitar o sistema na entrega e implantação do sistema?
5. Existem outros usuário internos ou externos cujas necessidades devem ser abordadas?
Processo de Engenharia de Requisitos
Página 8
6. Quem irá manter o sistema?
7. Existe mais alguém?
Utilizar os atores para identificar e definir as fronteiras do sistema, pois as informações são transferidas entre o sistema e os usuários que estão no mundo externo.
Aborde as restrições impostas ao sistema, que são de ordem política, econômica, ambiental, técnica, tecnológica e de viabilidade. As restrições devem ser cuidadosamente consideradas, pois elas estão diretamente relacionadas aos riscos a serem abordados.
Aplicar a seguinte sequência de perguntas, para obtenção das restrições:
1. Existe alguma determinação política interna ou externa que afeta a solução em potencial?
2. Que restrições financeiras são aplicáveis ao sistema? Existem custos de bens ou políticas de preços a considerar? Existe alguma restrição relativa a licença de uso?
3. Existe alguma restrição de ordem ambiental?
4. Estamos restritos, na nossa escolha de tecnologias? Existe alguma restrição em trabalhar com as tecnologias e plataformas disponíveis? Estamos proibidos de utilizar alguma tecnologia?
5. Cronograma está definido? Estamos restritos a recursos existentes? Poderemos utilizar mão-de-obra externa? Podemos expandir recursos temporaria ou permanentemente?
Devemos manter compatibilidade com soluções existentes? Que sistemas operacionais e ambientes devem ser suportados?
Para a formulação da declaração do problema, aplicar as seguintes perguntas:
O problema …………….……..<descrever o problema>
Afeta …………………..……….<listar os Stakeholders>
O impacto disto é…….………<qual o impacto do problema>
Uma boa solução seria ……..<listar alguns benefícios principais da solução>
Descreva as funcionalidades do sistema de forma resumida, defina atributos para auxiliar na determinação dos seus estados e prioridades no projeto.
PPrréé--ccoonnddiiççããoo § Ter recebido a sinalização de início do projeto.
PPóóss--ccoonnddiiççããoo § Ter um draft do documento de visão.
EEnntt rraaddaass § Contrato para desenvolvimento/Manutenção de Software
SSaaííddaass § Documento de visão
§ Glossário
FFuunnççããoo ((RReessppoonnssáávvee ll )) § Engenheiro de requisitos
MMééttooddooss ee TTééccnniiccaass § Entrevista
FFee rrrraammeennttaa § Requisite Pro
A.2 – Encontrar Atores
DDeessccrr iiççããoo Um ator é alguém ou alguma coisa que interage com o sistema. Existem três tipos de atores: usuários, dispositivos e outros sistemas. Atores não são parte do sistema sendo descrito, mas existem fora dos limites do sistema. Para encontrar os atores faça as seguintes perguntas: Que grupos de usuários requerem ajuda do sistema para realizar suas atividades? Que grupo de usuários são necessários para executar as principais, e óbvias, funções do sistema? Que grupo de usuários são requeridos para realizar funções secundárias, tais como administração e manutenção do sistema? O sistema irá interagir com qualquer sistema de hardware ou software externo? Qualquer indivíduo, grupo ou fenômeno que se encaixa em uma ou mais categorias destas é um provável ator. Registre os atores no Requisite Pro e, utilizando o Rational Syncronizer, transfira-os para o Rational Rose, para dar suporte ao futuro modelo de casos de Uso.
Processo de Engenharia de Requisitos
Página 9
Verifique pessoas, hardware e sistemas que realizem alguma interação com o sistema ou negócio. Estes serão os atores. Aplique a seguinte sequência de perguntas:
1. Que grupo de usuários necessita de ajuda do sistema para realizar suas tarefas?
2. Que grupo de usuários é necessário para executar as principais funções do sistema?
3. Que grupo de usuários é necessário para executar as funções secundárias do sistema, tais como manutenção e administração?
4. O sistema irá interagir com algum hardware ou software externo?
Registre os atores no Requisite Pro e, utilizando o Rational Syncronizer, transfira-os para o Rational Rose, para dar suporte ao futuro modelo de casos de Uso.
PPrréé--ccoonnddiiççããoo § Ter entendido o escopo e principais funcionalidades do sistema.
PPóóss--ccoonnddii ççããoo § Ter identificado os principais atores.
EEnntt rraaddaass § Glossário
§ Documento de Visão
SSaaííddaass § Modelo de Caso de Uso (somente com atores)
FFuunnççããoo ((RReessppoonnssáávvee ll )) § Engenheiro de requisitos
MMééttooddooss ee TTééccnniiccaass § Use-Case
§ Entrevistas
FFee rrrraammeennttaa § Requisite Pro
§ Rational Rose
§ Rational Syncronizer
A.3 – Capturar Vocabulário Comum
DDeessccrr iiççããoo Deve-se definir um vocabulário comum para facilitar a comunicação entre os envolvidos para que ele possa ser usado em todas as descrições textuais do sistema, especialmente nas descrições de use-case. Deve-se encontrar os termos comuns e avaliar os resultados. O glossário será evoluído na medida que se elicita os requisitos e os modela. Portanto, algumas entradas desta atividade acontecem ao longo do processo.
Para encontrar os termos comuns ao domínio do problema, considere os termos utilizados no registro dos requisitos e também o conhecimento geral da equipe de desenvolvimento, sobre o sistema a ser construído.
Os termos devem ser descritos como substantivos, no singular, seguidos de uma definição.
Analisar o Glossário e validar, com equipe de desenvolvimento, clientes e usuários se os termos estão coerentes e de fácil entendimento.
Os termos devem ser revistos superficialmente, considerando, principalmente, os seguintes check-points:
§ Cada termo tem uma definição clara e concisa e consistente?
Cada termo do glossário está referenciado nas descrições do negócio?
PPrréé--ccoonnddiiççããoo § Ter iniciado a elaboração do Documento de Visão.
PPóóss--ccoonnddii ççããoo § Não ter mais dúvidas de termos técnicos/ negócio do domínio do sistema.
EEnntt rraaddaass § Documento de Visão
§ Modelo de casos de uso
Processo de Engenharia de Requisitos
Página 10
SSaaííddaass § Glossario_de_Termos
FFuunnççããoo ((RReessppoonnssáávvee ll )) § Engenheiro de requisitos
MMééttooddooss ee TTééccnniiccaass § Use-Case, Entrevistas
FFee rrrraammeennttaa § Requisite Pro
§ Rational Rose
B. Entender as necessidades dos Stakeholders DDeessccrr iiççããoo Requisitos são criados por muitas fontes, por exemplo clientes, parceiros, usuários finais e especialistas do domínio. É necessário saber como determinar as fontes mais importantes, ter acesso a essas fontes e como melhor elicitar as informações vindas delas. Os indivíduos que fornece as fontes de informações mais importantes são denominados stakeholders do projeto. Frequentemente as discussões iniciam no nível de modelo de negócios e não no nível do sistema. Elicitações serão feitas usando a técnica de entrevistas. O resultado da elicitação deve ser uma lista de requisitos ou necessidades que são descritas textualmente e graficamente e com prioridades atribuídas.
Antes de elicitação de requisitos deve-se definir quais serão os atributos dos requisitos.
Deve-se estar atento que um produto pode satisfazer a especificação técnica dos requisitos e ainda assim não atingir as expectativas do cliente. Não é possível garantir que um produto irá atingir completamente as expectativas do cliente em uma única tentativa de especificação de requisitos. Tenta-se simplesmente listar as palavras como o usuário utiliza, mas perde-se grande parte das mensagens. Deve-se lembrar que os requisitos podem sempre ser mais completos ou mais precisamente definidos.
PPrréé--ccoonnddiiççããoo § Ter entendido o escopo, restrições e principais funcionalidades do sistema.
PPóóss--ccoonnddii ççããoo § Documentar os requisitos.
EEnntt rraaddaass § Documento de Visão
§ Modelo de casos de uso
§ Glossário de Termos
SSaaííddaass § Documento de visão refinado com especificação suplementar
FFuunnççããoo ((RReessppoonnssáávvee ll )) § Engenheiro de requisitos
MMééttooddooss ee TTééccnniiccaass § Use-Case, Entrevistas
FFee rrrraammeennttaa § Requisite Pro
§ Rational Rose
B1 – Definir atributos de Requisitos
DDeessccrr iiççããoo Determinar os atributos apropriados para os requisitos, como por exemplo, origem, custo e estabilidades. Estes atributos irão auxiliar nas tarefas de:
§ Designar recursos para o desenvolvimento do requisito
§ Avaliar status do requisito
§ Calcular métricas do software
Processo de Engenharia de Requisitos
Página 11
§ Gerenciar riscos do projeto
§ Estimar custo do projeto
§ Gerenciar o escopo do projeto
PPrréé--ccoonnddiiççããoo § Conhecer os atributos padrão para a organização.
PPóóss--ccoonnddiiççããoo § Configurar o Requisite Pro com os referidos atributos.
EEnntt rraaddaass § Documento de Visão
§ Guias de atributos
SSaaííddaass § Atributos dos requisitos
FFuunnççããoo ((RReessppoonnssáávvee ll )) § Engenheiro de requisitos
MMééttooddooss ee TTééccnniiccaass § workshop e storyboard de casos de uso
FFee rrrraammeennttaa § Requisite Pro
B.2 – Elicitar Requisitos dos Stakeholders
DDeessccrr iiccaaoo Deve-se entender quem são os stakeholders do sistema; coletar os requisitos referentes as necessidades que o sistema deve preencher e, priorizar as requisições dos stakeholders. Os passos são identificar a origem dos requisitos, coletar informações; conduzir entrevistas e avaliar os resultados.
Process Standard: Elabore a lista de expectativas do cliente classificando os requisitos como sendo requisitos reais (precisa ter) ou requisitos desejáveis (pode-se ter).
Deve-se também preencher os atributos definidos para os requisitos.
PPrréé--ccoonnddiiççããoo § Ter entendido o escopo, restrições e principais funcionalidades do sistema.
PPóóss--ccoonnddii ççããoo § Documentar os requisitos.
EEnntt rraaddaass § Documento de Visão
§ Glossário de Termos
§ Modelo de Caso de Uso
SSaaííddaass § Requisitos
FFuunnççããoo ((RReessppoonnssáávvee ll )) § Engenheiro de requisitos
MMééttooddooss ee TTééccnniiccaass § Entrevistas
FFee rrrraammeennttaa § -
Processo de Engenharia de Requisitos
Página 12
B.3 – Complementar Documento Visão
DDeessccrr iiççããoo Refinar o Documento de Visão em relação ao aprofundamento obtido na identificação das necessidades dos stakeholders. Os requisitos identificados são inseridos no documento de visão.
Acrescentar novas funcionalidades e refinar as já existentes.
PPrréé--ccoonnddiiççããoo § Ter o draft do Documento de Visão
PPóóss--ccoonnddiiççããoo § Utilizar o documento de visão como a base do desenvolvimento do projeto.
EEnntt rraaddaass § Documento de Visão
§ Glossário de Termos
§ Modelo de Caso de Uso
SSaaííddaass § Documento de Visão completo
FFuunnççããoo ((RReessppoonnssáávvee ll )) § Engenheiro de requisitos
MMééttooddooss ee TTééccnniiccaass § -
FFee rrrraammeennttaa § Requisite Pro
C. Definir o Sistema DDeessccrr iiççããoo Para definir o significado do sistema para traduzir e organizar o entendimento das necessidades dos stakeholders, uma descrição significativa deve ser feita. Inicialmente, na definição do sistema, decisões são feitas baseadas no que um requisito constitui, no formato da documentação, na formalidade da linguagem, no nível das especificações dos requisitos (quantos e em que detalhes), nas prioridades estabelecida e no esforço estimado, nos riscos técnicos e gerenciais e no escopo inicial. Uma parte desta atividade pode incluir protótipos preliminares e modelos de projetos diretamente relacionados com as solicitações mais importantes dos stakeholders. O material gerado da definição do sistema e uma descrição do sistema que é gráfica ou em linguagem natural.
PPrréé--ccoonnddiiççããoo § Ter o Documento de Visão
PPóóss--ccoonnddiiççããoo § Ter revisado os requisitos.
EEnntt rraaddaass § Documento de Visão
§ Glossário de Termos
§ Modelo de Caso de Uso
SSaaííddaass § Modelo de Caso de Uso (refinado)
§ Caso de Uso
FFuunnççããoo ((RReessppoonnssáávvee ll )) § Engenheiro de requisitos
MMééttooddooss ee TTééccnniiccaass § Use Case
Processo de Engenharia de Requisitos
Página 13
FFee rrrraammeennttaa § Requisite Pro
§ Rational Rose
C.1 – Elaborar a Lista de Casos de Uso
DDeessccrr iiççããoo A finalidade de encontrar atores e use cases é esboçar as funcionalidades do sistema; definir o que será tratado pelo sistema e o que será tratado fora do sistema; definir quem e o que interagirá com o sistema; dividir o modelo em pacotes com atores e use-cases; criar diagramas do modelo use-case e desenvolver uma visão do modelo use-case. A melhor maneira de encontrar use cases é considerar o que cada ator requer do sistema. Para cada ator faça os seguintes questionamentos: quais são as primeiras tarefas que o ator quer realizar com o sistema? O ator irá criar, armazenar, remover ou ler dados no sistema? O ator precisará informar ao sistema, repentinamente, sobre mudanças externas? O ator precisa ser informado sobre certas ocorrências do sistema? O ator poderá iniciar ou finalizar um sistema? As respostas para estas questões representam o fluxo de eventos que identificam use case candidatos.
§ Encontrar atores
§ Encontrar casos de uso
§ Descrever como atores e casos de uso interagem
§ Empacotar casos de uso e atores
§ Demostrar o modelo de casos de uso em diagramas (opcional)
§ Desenvolver uma análise do modelo de casos de uso
§ Avaliar resultados
Rever atores
Nesta etapa serão revistos os atores anteriormente identificados e verifica-se a existência de novos atores, quando do aprofundamento do entendimento das funcionalidades dos casos de uso.
Encontrar casos de uso
Serão definidos casos de uso preliminarmente, sem detalhamento, apresentando passo a passo as funcionalidades do mesmo.
Diretrizes
A melhor forma de identificar casos de uso é considerar o que é requerido pelos atores.
Descrever como atores e casos de uso interagem
Apresentar os relacionamentos entre os atores e os casos de uso que participam.
Diretrizes
O sinal de comunicação entre atores e casos de uso podem ter um ou dois sentidos. O sentido indica quem efetua a comunicação.
Empacotar casos de uso e atores
Caso tenhamos um grande número de atores e casos de uso devemos empacotá-los para ganharmos simplicidade na manutenção do modelo de casos de uso. Assim tornaremos o modelo mais fácil de captar e mais simples para definir responsabilidades nos modelos de caso de uso para os desenvolvedores envolvidos no processo.
Diretrizes
Demonstrar o modelo de casos de uso em diagramas
Criação de diagramas que reflitam as informações obtidas nos Descrição anteriores. Estas informações são relativas as identificações dos atores e caso de uso, seus relacionamentos e o devido empacotados destes.
Diretrizes
Desenvolver uma análise do modelo de casos de uso
Desenvolver uma análise da descrição de casos de uso, validando as seqüências típicas que um usuário irá utilizar e verificando funcionalidade não cobertas pelo caso de uso.
Diretrizes
Avaliar resultados
Cliente e usuário deverão ser envolvidos para validarem o conteúdo dos casos de uso. Equipes externas ao projeto devem ser envolvidas para validação da forma do caso de uso.
Processo de Engenharia de Requisitos
Página 14
PPrréé--ccoonnddiiççããoo § Ter o Documento de Visão
PPóóss--ccoonnddiiççããoo § Ter obtido a lista de casos de uso.
EEnntt rraaddaass § Glossário
§ Documento de Visão
§ Solicitações dos Stakeholders
§ Guia de modelagem de casos de uso
SSaaííddaass § Modelo de casos de uso ( refinado )
§ Caso de uso
FFuunnççããoo ((RReessppoonnssáávvee ll )) § Engenheiro de requisitos
MMééttooddooss ee TTééccnniiccaass § Caso de uso
FFee rrrraammeennttaa § Requisite Pro, Rational Rose
C.2 – Revisar Requisitos
DDeessccrr iiççããoo ((PPrroocceessss SSttaannddaarrdd))
Identificar, por exemplo, se algum requisito esta ausente, se os requisitos podem ser implementados, se estão bem declarados, consistentes uns com os outros, se são testáveis e implementáveis. Documentar as alterações necessária e negociar os compromissos resultantes com os grupos envolvidos e os gerentes de software. O objetivo é verificar formalmente se os requisitos estão em conformidade com a visão do cliente do sistema.
RReesstt rr iiççããoo § Antes de incorporá-los ao projeto de software
PPrréé--ccoonnddiiççããoo § Ter o Documento de Visão, o Modelo de Caso de uso e a Lista de casos de uso
PPóóss--ccoonnddiiççããoo § Obter acordo com relação aos requisitos e casos de uso a serem tratados no projeto.
EEnntt rraaddaass § Política organizacional
§ Recursos e fundos
§ Treinamentos
§ Documento de Visão
§ Glossário
§ Modelo de casos de uso
§ Descrições de Casos de uso
§ Especificação suplementar
SSaaííddaass § Requisitos revistos e documentados
§ Lista de questões
FFuunnççããoo ((RReessppoonnssáávvee ll )) § Engenheiro de requisitos
§ Stakeholders
§ Usuários
Processo de Engenharia de Requisitos
Página 15
MMééttooddooss ee TTééccnniiccaass § Workshop de requisitos
D. Definir a Iteração DDeessccrr iiççããoo
O propósito deste sub-processo é:
§ definir entradas para seleção dos requisitos que serão incluídos na iteração corrente;
§ definir o conjunto de funcionalidades e Casos de Uso (ou cenários) que representam alguma funcionalidade central e significativa;
§ definir quais atributos de requisitos e traceability devem ser gerenciados.
PPrréé--ccoonnddiiççããoo § Ter o Modelo de Caso de uso e a Lista de casos de uso revisada
PPóóss--ccoonnddiiççããoo § Obter acordo com relação aos requisitos e casos de uso a serem tratados na iteração.
EEnntt rraaddaass § Modelo de casos de uso
§ Lista de casos de uso
SSaaííddaass § Modelo de caso de uso da iteração
FFuunnççããoo ((RReessppoonnssáávvee ll )) § Engenheiro de requisitos
MMééttooddooss ee TTééccnniiccaass § Use case
§ Workshop de requisitos
FFee rrrraammeennttaa § Requisite Pro, Rational Rose
D.1 – Elaborar modelo de casos de uso da iteração
DDeessccrr iiççããoo A finalidade é criar ou refinar o modelo de caso de uso da iteração. Esta tarefa será realizada uma vez para cada iteração. Realiza-se uma análise do modelo de casos de uso referente aos use-cases da iteração em questão. O resultado esperado deste trabalho é um modelo de use-cases refinado, ou seja, contemplando as possíveis relações de “use” e “include” entre os use-cases.
PPrréé--ccoonnddiiççããoo § Ter o Modelo de Caso de uso e a Lista de casos de uso revisada
PPóóss--ccoonnddiiççããoo § Obter acordo com relação aos requisitos e casos de uso a serem tratados na iteração.
EEnntt rraaddaass § Modelo de casos de uso
§ Lista de casos de uso
SSaaííddaass § Modelo de caso de uso da iteração
FFuunnççããoo ((RReessppoonnssáávvee ll )) § Engenheiro de requisitos
MMééttooddooss ee TTééccnniiccaass § Use case e workshop de requisitos
FFee rrrraammeennttaa § Requisite Pro, Rational Rose
Processo de Engenharia de Requisitos
Página 16
E. Gerenciar Escopo do Sistema (Iteração) DDeessccrr iiccaaoo:: O escopo de um projeto está definido pelo conjunto de requisitos alocados para ele. Gerenciar o escopo é uma atividade contínua que divide o escopo do projeto em pequenas partes gerenciáveis. Para fazer um projeto de forma eficiente, é necessário priorizar os requisitos cuidadosamente, baseado na informações de todos os stakeholders, e gerenciar seu escopo. Muitos projetos sofrem o problema dos desenvolvedores trabalharem em features que eles acham interessantes e desafiadoras ao invés de focarem na tarefas que aliviam os riscos do projeto ou que estabilizam a arquitetura da aplicação. Para ter certeza que os riscos de um projeto são resolvidos ou minimizados o quanto antes, o sistema deve ser desenvolvido de forma incremental e escolhendo cuidadosamente os requisitos para cada iteração de forma a aliviar os riscos conhecidos do projeto. Para realizar isso, é necessário negociar o escopo de cada iteração com os stakeholders do projeto. Isto geralmente necessita alto conhecimento em gerência de especificações em diferentes fases do projeto. Utilizar os atributos dos requisitos, tais como prioridade, custo, esforço e risco, é particularmente uma técnica útil para gerenciar o escopo, pois é eles são a base para negociar a inclusão de um requisito nas iterações.
PPrréé--ccoonnddiiççããoo § Ter o Modelo de Caso de uso e a Lista de casos de uso revisada
PPóóss--ccoonnddiiççããoo § Ter obtido acordo da priorização dos casos de uso
EEnntt rraaddaass § Documento de Visão
§ Modelo de casos de uso
§ Lista de casos de uso
§ Atributos de Requisitos
SSaaííddaass § Modelo de caso de uso da iteração
§ Glossário ( refinado )
§ Plano de Iteração ( refinado )
FFuunnççããoo ((RReessppoonnssáávvee ll )) § Engenheiro de requisitos
MMééttooddooss ee TTééccnniiccaass § Use case
FFee rrrraammeennttaa § Requisite Pro
§ Rational Rose
E.1 – Priorizar Casos de uso
DDeessccrr iiççããoo No processo de requisitos da Rational, que utiliza o ciclo de vida espiral, primeiro se obtém os requisitos macros e estes são posteriormente detalhados nas iterações. No entanto, deve-se priorizar os use case que serão abordados, detalhados primeiro, nas iterações iniciais. Existem três ranks (classificações) para as use cases e classes: a) Críticos (ou principais) que fazem as principais tarefas do sistema, suas funções básicas, para as quais ele está sendo desenvolvido. Se eles falham a missão principal do sistema falha; b) Importantes (ou secundários) que estão relacionados com o suporte às funções, exemplos são, compilação de dados estatísticos, geração de relatórios e testes. Se não forem atendidos o sistema ainda atende sua função principal embora a qualidade do serviço fique degradada; c) Menos importantes, os quais não estão ligados a missão principal do sistema, mas ajudam no seu uso ou posição de mercado. Em geral o impacto na arquitetura está correlacionado com a criticidade. Portanto, use case mais críticos que tenham impacto na arquitetura devem ser abordados primeiro. Utiliza-se como entrada o plano de iterações inicializado no planejamento do projeto. De acordo com as priorizações ele pode ser alterado.
§ Priorizar cenários e casos de uso
§ Documentar visão de casos de uso (use case view)
§ Analisar os resultados
Processo de Engenharia de Requisitos
Página 17
Priorizar cenários e casos de uso
O Analista de Sistemas identifica os requisitos funcionais, e seus atributos, mapeados pelos cenários e casos de uso da iteração corrente. Com esta informações os cenários e casos de uso são categorizados e priorizados, baseando-se também nos riscos a serem minimizados.
Diretrizes
Existem três classificações para se priorizar casos de uso :
§ Crítico : Casos de uso que mapeam as funcionalidade principais e fundamentais
§ Importante : Necessário para suportar funções do sistema
§ Desejável : funcionalidade que não se relacionam diretamente com as funções primárias, mas ajudam o uso destas
Documentar visão de casos de uso (use case view)
O Analista de Sistemas cria a visão dos casos de uso no documento de arquitetura do software, para a iteração corrente.
Diretrizes
Analisar os resultados
É avaliado se as informações da visão de casos de uso estão corretas. Não existe uma revisão detalhada desta visão, porém é verificado se nenhum caso de uso ou cenário foi esquecido.
Diretrizes
PPrréé--ccoonnddiiççããoo § Ter o Modelo de Caso de uso e a Lista de casos de uso revisada
PPóóss--ccoonnddiiççããoo § Ter obtido acordo da priorização dos casos de uso
EEnntt rraaddaass § Documento de Visão
§ Modelo de casos de uso
§ Lista de casos de uso
§ Atributos de Requisitos
§ Plano de Iteração
SSaaííddaass § Modelo de caso de uso da iteração
§ Documento de arquitetura de software (refinamento da visão de caso de uso para iteração corrente )
§ Glossário ( refinado )
§ Plano de Iteração ( refinado de acordo com as priorizações)
FFuunnççããoo ((RReessppoonnssáávvee ll )) § Engenheiro de requisitos
MMééttooddooss ee TTééccnniiccaass § Use case
FFee rrrraammeennttaa § Requisite Pro
§ Rational Rose
F. Refinar a Definição da Iteração DDeessccrr iiccaaoo:: A definição detalhada do projeto do sistema deve ser feita de modo que os stakeholders possam entender e concordar com elas. É necessário cobrir não somente as funcionalidades, mas também compatibilidade com qualquer requisito regulatório e legal, usabilidade, confiabilidade, performance, suportabilidade e mantenibilidade. Um erro frequentemente cometido é pensar que algo difícil de ser feito precisa ter uma definição complexa. É preciso despender esforço para que os documentos que descrevem o sistema sejam entendidos. Pode haver a necessidade de produzir diferentes tipos de documentos para diferentes públicos alvo. Um outro componente da definição do sistema é a descrição de como o sistema deve ser testado. Planos de teste e definições dos testes devem ser feitos para verificar as capacidades do sistema.
Processo de Engenharia de Requisitos
Página 18
PPrréé--ccoonnddiiççããoo § Ter definido os use cases da iteração.
PPóóss--ccoonnddiiççããoo § Ter recebido feedback do usuário com respeito ao protótipo do sistema.
EEnntt rraaddaass § Documento de Visão
§ Glossário
§ Caso de uso
§ Modelo de casos de uso
§ Guia de modelagem de caso de uso
§ Guia de atributos de requisitos
SSaaííddaass § Caso de uso ( completamente descrito )
§ Documento de Visão revistos
§ Atributos de requisitos
§ Planos de teste
FFuunnççããoo ((RReessppoonnssáávvee ll )) § Engenheiro de requisitos
MMééttooddooss ee TTééccnniiccaass § Casos de uso
FFee rrrraammeennttaa § Requisite Pro
§ RationalRose
F.1 – Detalhar Casos de Uso
DDeessccrr iiççããoo A finalidade desta atividade é descrever em detalhes o fluxo de eventos do use case; e descrever o fluxo de eventos de forma que o cliente e os usuários possam entender. Os passos são detalhar o fluxo de eventos do use case; estruturar o fluxo de eventos do use case; ilustrar o ralacionamento entre os atores e outros use case; descrever os requisitos especiais do use case; descrever os protocolos de comunicação; descrever as pré-condições do use case (opcional); descrever as pós-condições do use case (opcional); descrever os pontos de extensão (opcional) e avaliar os resultados.
§ Detalhar o fluxo de evento do caso de uso
§ Estruturar o fluxo de evento do caso de uso
§ Ilustrar o relacionamento entre atores e outros casos de uso
§ Descrever requisitos especiais para caso de uso
§ Descrever protocolos de comunicação
§ Descrever pré e pós condições do caso de uso ( opcional )
§ Descrever pontos de extensão ( opcional )
§ Avaliar resultados
Detalhar o fluxo de evento do caso de uso
O Analista de Sistemas, baseado nas especificações passo a passo do caso de uso, refina a descrição do mesmo, detalhando o máximo possível, considerando facilitar o entendimento, desta descrição, por clientes e usuários.
Diretrizes
Estruturar o fluxo de eventos do caso de uso
O Analista de Sistemas analisa o caso de uso e detalha caminhos alternativos, chamados de sub flows. Cada subflow é uma ação possível de acontecer, porém não é o fluxo normal do caso de uso.
Diretrizes
Ilustrar o relacionamento entre atores e outros casos de uso
Processo de Engenharia de Requisitos
Página 19
Neste passo é criado o modelo de casos de uso que tem como função identificar o relacionamento do caso de uso com os atores e/ou com outros casos de uso.
Diretrizes
Descrever requisitos especiais para casos de uso
Descrever todos requisitos ,na seção requisitos especiais, relacionados com o caso de uso que não estejam sendo considerados no fluxo de eventos do caso de uso.
Diretrizes
Descrever protocolos de comunicação
se há atores que são outros sistemas ou alguma comunicação com hardware externo deve-se desenvolver protocolos de comunicação.
Diretrizes
Descrever pré e pós condições do caso de uso
Descrever pré e pós condições quando necessário.
Diretrizes
Descrever pontos de extensão
Se o caso de uso for estendido para outro(s) caso(s) de uso estes pontos de extensão devem ser descritos.
Diretrizes
Avaliar resultados
Devem ser discutidos os casos de uso com os Stakeholders para que se esteja certo que todas as possibilidades e variáveis do caso de uso foram abordadas.
PPrréé--ccoonnddiiççããoo § Ter definido os use cases da iteração.
PPóóss--ccoonnddiiççããoo § Ter uma descrição detalhada dos casos de uso.
EEnntt rraaddaass § Documento de Visão
§ Glossário
§ Caso de uso
§ Modelo de casos de uso
§ Guia de modelagem de caso de uso
§ Guia de atributos de requisitos
SSaaííddaass § Caso de uso ( completamente descrito )
§ Documento de Visão
FFuunnççããoo ((RReessppoonnssáávvee ll )) § Engenheiro de requisitos
MMééttooddooss ee TTééccnniiccaass § Casos de uso
FFee rrrraammeennttaa § Requisite Pro
§ Rational Rose
F.2 – Modelar Interface do Usuário
DDeessccrr iiççããoo Construir um modelo de interface com o usuário que suporte todo o conteúdo e conhecimento do sistema, sempre tendo em mente a reutilização. As tarefas a serem realizadas são:
Descrever as características dos atores relacionados
O engenheiro de requisitos descreve as características dos atores ( humanos ). Deve ser dado foco nos atores primários e os que tem mas interação no caso de uso.
Criar storyboards dos casos de uso
Processo de Engenharia de Requisitos
Página 20
O engenheiro de requisitos deve gerar um storyboard do caso de uso e relacioná-lo com o caso de uso originário.
Descrever o fluxo de evento – storyboard
As descrições passo a passo de cada caso de uso devem ser refinadas e o foco deve ser estar nas características de usabilidade. Este refinamento deve ser compilado no fluxo de evento – storyboard.
Capturar requisitos de lnterface – storyboard
Capturar requisitos de interface, definindo um nível de usabilidade o maior possível.
Identificar classes de interface necessárias ao caso de uso para o storyboard identificado
Neste momento devem ser identificadas as classes de interface primitivas e as centrais.
Descrever interações entre atores e classes de interface
Identificar as interações entre atores e classes de interface, definindo as responsabilidades, da segunda, para suportar o conteúdo visível deste relacionamento. É gerado um diagrama de colaboração Complementar diagrama do storyboard do caso de uso
Este passo é opcional e só é executado caso seja necessário complementar ou clarear as informações contidas no diagrama de colaboração referenciadas ao protótipo.
Remeter o protótipo ao storyboard do caso de uso
Este passo é opcional e só é executado caso seja necessário complementar ou clarear as informações contidas no diagrama de colaboração referenciadas ao protótipo.
PPrréé--ccoonnddiiççããoo § Ter especificado os casos de uso.
PPóóss--ccoonnddiiççããoo § Ter obtido uma modelagem satisfatória.
EEnntt rraaddaass § Caso de uso
§ Atores
§ Documento de Visão
§ Guia de casos de uso
SSaaííddaass § Storyboard de caso de uso
§ Atores
§ Classes de interface
FFuunnççããoo ((RReessppoonnssáávvee ll )) § Designer de Interface
MMééttooddooss ee TTééccnniiccaass § Casos de uso
FFee rrrraammeennttaa § Requisite Pro,
§ Rational Rose
E.4 – Prototipar interface do usuário
DDeessccrr iiççããoo A finalidade desta atividade é construir um protótipo com a interface com o usuário ou seja:
Desenhar o protótipo de interface com o usuário
Deverá ser desenhada a interface do sistema inicialmente identificando as telas principais com suas características, como serão operadas e suas propriedades. Deverão ser, posteriormente, definidas as telas com multiplos objetos. A seguir serão definidas as demais telas e funções diversas.
Implementar o protótipo de interface com o usuário
Deverão ser desenhadas as tela e desenvolvidos bitmaps, se necessário. Deve-se implementar funcionalidades e criar executáveis, concluindo o protótipo.
Obter feedback do protótipo de interface com o usuário
Deve ser mostrado e validado o protótipo para membros de outro projeto, experts externos em usabilidade. Usuários devem ser envolvidos para validarem a usabilidade e a completeza do protótipo.
Processo de Engenharia de Requisitos
Página 21
PPrréé--ccoonnddiiççããoo § Ter especificado e modelado os casos de uso.
PPóóss--ccoonnddiiççããoo § Receber feedback dos usuários.
EEnntt rraaddaass § Storyboard do caso de uso
§ Classe de interface
§ Atores
§ Documento de Visão
SSaaííddaass § Protótipo de interface com o usuário
FFuunnççããoo ((RReessppoonnssáávvee ll )) § Designer de Interface.
FFee rrrraammeennttaa § VB
G. Gerenciar requisitos DDeessccrr iiççããoo As alterações nos requisitos impactam naturalmente os modelos produzidos, bem como os modelos de teste. As relações de traceability entre requisitos é a chave para entender o impacto das mudanças.
O propósito de gerenciar requisitos é:
§ gerenciar a dependência entre requisitos, configurando apropriadamente os atributos dos requisitos e a traceability;
§ Gerenciar a mudança dos requisitos verificando o impacto e utilizar um processo de solicitação de mudanças.
As solicitações de mudanças devem ser registradas no workflow do ClearQuest.
PPrréé--ccoonnddiiççããoo § Ter definido os requisitos.
PPóóss--ccoonnddiiççããoo § Alterar produtos impactados pelas mudanças.
EEnntt rraaddaass § Documento de Visão
§ Modelo de caso de uso
§ Casos de uso
§ Solicitação de mudança
§ Atributos dos requisitos
§ Lista de riscos
SSaaííddaass § Matriz de rastreabilidade
§ Análise da solicitação de mudança
FFuunnççããoo ((RReessppoonnssáávvee ll )) § Engenheiro de requisitos.
FFee rrrraammeennttaa § Requisite Pro
§ Rational Rose
§ ClearQuest
Processo de Engenharia de Requisitos
Página 22
G. 1 – Gerenciar Dependências entre Requisitos
DDeessccrr iiççããoo Criar dependência entre requisitos e os novos casos de uso criados e desenvolver uma análise do modelo de casos de uso.
A finalidade é garantir a integridade das dependência após a criação de novos casos de uso e atores. Devem ser revisadas as dependências para cada caso de uso refinado, seja por "includes" ,"extends" ou generalizações.
Deve-se entender os atributos dos requisitos ajudando na gerência do escopo do projeto e da aplicação. Os passos são escolher os atributos dos requisitos; usar os atributos dos requisitos e estabelecer a rastreabilidade. Cada projeto pode ter seus atributos específicos, que diferem de acordo com o tipo de elemento que está sendo acompanhado. Exemplos de atributos podem ser a)“status (estado) do requisito” (proposto, aprovado, incorporado, validado e rejeitado); b)risco (probabilidade de impacto no projeto, ou seja, no cronograma, orçamento e técnico); c) responsabilidade (quem é responsável pelo requisitos); d) origem (fonte do requisito); e) estabilidade (a probabilidade do requisito mudar) e f) prioridade (refere-se a opnião do cliente). Utilizando os atributos dos requisitos pode-se, por exemplo, avaliar o status dos requisitos, gerenciar o risco do projeto, estimar custos e gerenciar o escopo do projeto.
Mapear requisitos funcionais para casos de uso
Serão mapeados todos os requisitos funcionais contidos no documento de Documento de Visão em relação aos novos casos de uso ou a seqüências do caso de uso
Mapear requisitos de Stakeholder para requisitos funcionais
Serão mapeados todas as necessidades dos stakeholders contidos no Documento de Visão em relação aos requisitos funcionais e em relação aos novos casos de uso ou a seqüências do caso de uso
Mapear requisitos não funcionais para casos de uso
Serão mapeados todos os requisitos não funcionais contidos no Documento de Visão em relação aos novos casos de uso ou a seqüências do caso de uso
PPrréé--ccoonnddiiççããoo § Ter definido os requisitos.
PPóóss--ccoonnddiiççããoo § Atualizar a matriz de traceability
EEnntt rraaddaass § Documento de Visão
§ Modelo de caso de uso
§ Casos de uso
§ Atributos de Requisito
§ Lista de Riscos
SSaaííddaass § Matriz de traceability
FFuunnççããoo ((RReessppoonnssáávvee ll )) § Engenheiro de requisitos.
MMééttooddooss ee TTééccnniiccaass § Não aplicável
FFee rrrraammeennttaa § Requisite Pro
G.2 – Gerenciar mudanças nos requisitos
DDeessccrr iiççããoo ((Process Standard – CMM)
Revisar as alterações nos requisitos alocados e incorporá-las ao projeto de software (atividade 3). O impacto nos compromissos existentes é avaliado e mudanças são negociadas quando apropriado, as alterações que precisam ser feitas nos planos de software, artefatos e atividades resultantes das alterações dos requisitos são controladas (identificadas, avaliadas, documentadas ...).
PPrréé--ccoonnddiiççããoo § Ter as responsabilidades estabelecidas para analisar e alocar os requisitos
§ Ter recebido uma solicitação de mudança (ClearQuest)
Processo de Engenharia de Requisitos
Página 23
PPóóss--ccoonnddiiççããoo § Usar os requisitos alocados
§ Realizar as alterações nos produtos impactados pela mudança
EEnntt rraaddaass § Solicitação de mudança
§ Documento de Visão
§ Casos de uso
§ Modelo de Casos de Uso
SSaaííddaass § Análise da solicitação de mudança
FFuunnççããoo ((RReessppoonnssáávvee ll )) § Engenheiro de requisitos.
FFee rrrraammeennttaa § Requisite Pro
§ Rational Rose
§ ClearQuest
3. Tabelas Auxiliares
3.1. Política O projeto é estratégico para a empresa e o contrato é preço fechado, portanto a documentação e a formalização dos requisitos é fundamental. Toda a mudança deve ser formalizada e discutida para definir o impacto no projeto e se necessário a negociação de mudança de escopo. A técnica de use case deve ser utilizada e a ferramenta RequisitePro deve ser utilizada para armazenar os requisitos.
3.2. Conceitos AArrtteeffaattoo Produto gerado durante o processo de desenvolvimento de software.
AAttoo rr Alguém ou algo que realiza interação direta com o sistema ou negócio, e que esteja fora de suas fronteiras. Quaisquer outros sistemas que interagem com o sistema em questão também são considerados atores.
AAtt rr iibbuuttoo ddee RReeqquuiissii ttoo Informação associada com um requisito e que fornece um link entre o requisito e outro elemento do projeto, como por exemplo prioridade, status, recurso, custo, dentre outros.
BBaassee ll iinnee Conjunto de produtos aceitos e controlados e que serão utilizados em atividades posteriores à sua aceitação.
CChheecckk--ppooiinnttss Pontos de verificação. Marcos onde são feitas verificações do andamento de uma atividade, processo ou produção de artefato.
CCrr ii ttéérr iiooss ddee AAcceeii ttaaççããoo Definem condições e circunstâncias para aceitar que o artefato está correto, ou seja, corresponde exatamente à sua especificação e opera tal como é esperado.
EEllaabboo rraattiioonn ((EEllaabboo rraaççããoo)) Fase que tem o foco no refinamento do entendimento global do sistema, com vistas à minimização dos riscos. Nesta fase, iniciamos a criação da arquitetura do sistema.
Processo de Engenharia de Requisitos
Página 24
EEll iiccii ttaarr Descobrir, tornar explicito, obter o máximo de informações para o conhecimento do objeto em questão. Do inglês elicit.
IInncceeppttiioonn((IInniicciiaaççããoo)) Fase inicial do processo RUP. Esta fase dá ênfase ao macro-entendimento do problema, onde são levantados os requisitos do sistema.
II ttee rraaççããoo Uma iteração circunda as atividades de desenvolvimento que levam à uma versão do produto (uma versão estável e executável do produto, junto com qualquer outro elemento periférico necessário para utilização desta versão). Então, uma iteração é uma passada completa através de todos os seguintes fluxos de trabalho(workflows): Gerência de Requisitos, Análise e Design, Implementação e Teste. É um pequeno projeto em cascata (waterfall) dentro do projeto como um todo.
RReeqquuii ssii ttoo Condição ou capacitação que deve ser atingida ou possuída por um sistema ou componente de sistema para satisfazer uma condição ou capacitação requerida por um cliente ou usuário final
RRUUPP Rational Unified Proccess – Processo aplicado ao desenvolvimento de software. Se baseia em fluxos de trabalho(Workflows) e fases(Inception, Elaboration, Construction, Transition)
SSttaakkeehhoo llddeerr Pessoas que possuem interesse no sistema a ser desenvolvido e que colaboram com sua definição, ou seja, pessoas que afetam ou são afetadas pelo sistema a ser desenvolvido. Podem ser: clientes, usuários, investidores, gerentes, compradores.
SSttoo rryybbooaa rrdd Representação gráfica de um fluxo de eventos do caso de uso
RRaasstt rreeaabbii ll iiddaaddee (( tt rraacceeaabbii ll ii ttyy)) É a característica que permite realizar o rastreamento de requisitos. Os propósitos da rastreabilidade são:
§ Verificar se todos os requisitos do sistema estão sendo contemplados na implementação;
§ Verificar se a aplicação faz somente aquilo que é esperado que ela faça;
§ Gerenciar mudanças.
CCaassooss ddee uussoo ((uussee ccaassee)) Um use case é uma seqüência de ações que um sistema executa e que produz um resultado de valor observável para um ator em particular. Os use cases provêem um meio para documentar requisitos funcionais que servem como base para o desenvolvimento de projetos, teste e planejamento de iterações.
3.3. Funções Tabela de Conversão Rational – Empresa Y
Rational Empresa Y
Use-case Specifier (especificador de use-case) Engenheiro de Requisitos (Analista de sistemas )
User-interface Designer (projetista) Engenheiro de Requisitos (Analista de sistemas Pl)
Architect (arquiteto) Designer (Analista de sistemas Sr)
Requirement Reviewer (revisor de requisitos) Revisor (Engenheiro de Requisitos)
Stakeholders/ Usuários Stakeholders/ Usuários
OO eessppeeccii ff ii ccaaddoorr ddoo uussee --ccaassee ((UUssee--ccaassee SSppeeccii ff iieerr)) :: um analista com dedicação exclusiva para trabalhos relacionados com a elicitação, análise e definição de requisitos e casos de uso.. O especificador do use-case (Use-case Specifier) detalha a especificação de uma parte da funcionalidade do sistema descrevendo os aspectos dos requisitos de um ou vários use cases. O especificador de use-case pode também ser responsável pelo pacote de use-case e da manutenção da integridade do pacote.
Processo de Engenharia de Requisitos
Página 25
PPrroojjeett iissttaa:: um recurso com conhecimento técnico voltado para interface e prototipação. O designer (projetista) de interfaces dos usuários guia e coordena a prototipação e projeto da interface do usuário: capturando os requisitos de interface dos usuários, incluindo requisitos de usabilidade; fazendo protótipos da interface do usuário envolvendo outros stakeholders da interface do usuário, como usuários finais, em revisões de usabilidade e sessões de teste de uso, revendo e provendo um feedback apropriado para a implementação final da interface do usuário.
AArrqquuiitteettoo : um analista que detém conhecimentos de arquitetura e que atua juntamente com o especialista de requisitos para realizar a priorização dos casos de uso. O arquiteto lidera e coordena atividades técnicas e artefatos através do projeto. Ele estabelece a estrutura geral para cada visão da arquitetura: a decomposição das visões, o agrupamento de elementos, e as interfaces entre os principais agrupamentos.
SSttaakkeehhoo llddeerrss: Outros nomes: indivíduos e grupos externos a organização (CMM; atores do universo de informação São pessoas ou organizações que serão afetadas pelo sistema e que tem uma direta ou indireta influência no sistema de requisitos. Incluem usuários finais do sistema, gerentes e outros envolvidos no processo organizacional influenciado pelo sistemas, engenheiros responsáveis pelo desenvolvimento/ manutenção do sistema, clientes da organização que utilizarão o sistema para prover algum serviço, entidades externas, tais como, autoridades de certificação ou regulamentação.
RReevviissoorr :: um especialista de requisitos, usuários ou stakeholders que verificam se os requisitos estão contemplando as necessidades da organização contratante do projeto.
Processo de Engenharia de Requisitos
Página 26
3.4. Medições Nome Descrição Tempo gasto com gerência de requisitos Total do tempo gasto com os processos de gerência de
requisitos
Qtd. de Requisitos func. não suportados em casos de uso
Identificar quantidade de requisitos que faltam implementar
Percentual de requisitos mapeados com caso de uso Posição atual de requisitos que já estão contemplados em casos de uso
Percentual de requisitos analisados Posição atual de requisitos que já estão contemplados nos artefatos de Analise & Design
Percentual de requisitos implementados Posição atual de requisitos que já estão contemplados em código
Percentual de requisitos testados Posição atual de requisitos que já estão contemplados em código e testados
Percentual de requisitos em produção Posição atual de requisitos que já estão contemplados em código, testados e já em produção no cliente
3.5. Treinamento Nome Objetivo Treinamento no processo de Engenharia de Requisitos Capacitar os recursos na técnica de casos de uso,
fundamental para a metodologia
Modelagem de caso de uso no Rose Modeler Capacitar os recursos em desenhar diagrama na ferramenta Rose Modeler
Requisite Pro Capacitar recursos para gerenciar requisitos através da ferramenta Requisite Pro
3.6. Ferramentas Nome Objetivo Rational Rose Ferramenta de modelagem da Rational. Utilizada no
projeto para para detalhar use cases (casos de uso).
RequisitePro É uma ferramenta da Rational, cuja finalidade é documentar (BD) e gerenciar requisitos. Possui uma matriz de controle de requisitos onde pode-se cruzar requisitos com os casos de uso. Também pode-se ter hierarquia de requisitos.
ClearQuest É uma ferramenta da Rational, cuja finalidade é manter um workflow desenvolvido pela Empresa Y para controle de mudanças.
3.7. Verificações
Nome Objetivo Tipo de verificação
Freqüência Quem realiza?
RevReqAlocados A revisão dos requisitos tem por objetivo obter o acordo dos envolvidos quanto aos requisitos que foram definidos para o projeto em
Revisão Toda vez que for estabelecido uma baseline
Usuário responsável, engenheiro requisitos e grupos
Processo de Engenharia de Requisitos
Página 27
questão. de requisitos e antes de serem incorporados ao projeto.
envolvidos
Processo de Engenharia de Requisitos
Página 28
3.8. Métodos/ Técnicas Nome Descrição Restrição ProdutoGerado Referência Entrevista O que é? Um meio bastante usual para coletar fatos.
Porque utilizar? Para coletar fatos
Quando se aplica? Quando há a possibilidade de contato direto com os atores que detêem conhecimento sobre os objetivos do software e a possibilidade da validação imediata através de processos de comunicação que enfatizam a confirmação.
Como se usa? As entrevistas fechadas devem dirigir o usuário para questões específicas de requisitos que precisam ser elicitados. As entrevistas abertas devem permitir ao usuário falar de suas tarefas.
Alguns pontos devem ser observados nas entrevistas:
1. Mantenha a comunicação efetiva: a comunicação é mais efetiva quando o entrevistador e entrevistado dividem a mesma linguagem, cultura, conhecimento educacional, familiaridade com o assunto. Algumas soluções são:
• aprender a terminologia do entrevistado e
• confirmar o entendimento obtido – o entrevistador checa continuamente se o que ele pensa é o que o entrevistado disse que significa.
2. Seja sensitivo com o entrevistado: adapte seu estilo ao dele. Esteja atento a:
• Sentimentos do entrevistado (inclusão – trate o problema dele como sendo seu também – ; respeito – ao conhecimento dele e ao tempo dele, tornando efetiva a reunião; paciência – mostre que você entende a dificuldade do papel dele e quando não obtiver a resposta, depois de várias tentativas, pare e tente ver a perspectiva dele).
• Comunicação não verbal do entrevistado
• Diferenças culturais entre você e o entrevistado.
As entrevistas abertas são inadequadas para elicitar informações detalhadas ou para descrever em detalhes as tarefas do usuário.
Notas Open-ended interview (Graham and Jones, 1988)
A practical guide to Knowledge Acquisition, Scott, A.C, Clayton J.E., Gibson E. L., Addison-Wesley, 1991
Processo de Engenharia de Requisitos
Página 29
Nome Descrição Restrição ProdutoGerado Referência Use Case O que é? técnica-chave para definir e especificar requisitos
de uma aplicação. Um use case é uma sequência de ações que um sistema realiza que agrega um valor para um ator particular. Um ator é alguém ou algo fora do sistema que interage com o sistema. Uma sequência de ações é um fluxo específico de eventos através do sistema.
Porque utilizar? Porque eles são intuitivos e se adaptam muito bem tanto com estilos orientados a objetos quanto com estilos funcionais.
Quando se aplica? Na definição e especificação de requisitos de uma aplicação.
Como se usa? Define-se um modelo de use case e especifica-se cada deles.
O modelo de use case é um modelo que descreve os requisitos do sistema e termos de use cases. Sua finalidade é comunicar o comportamento do sistema para o usuário final ou cliente.
• Identifica-se os atores e use cases usando os requisitos clientes e potencias usuários;
• Descreve-se brevemente os atores e use cases;
• Revisa-se o modelo de use case (Cliente) para verificar que todos os atores e casos de uso foram encontrados e que juntos eles podem fornecer o que o Cliente quer;
• Detalha-se o fluxo de eventos de cada caso de uso.
• Revisa-se o modelo de casos de uso, com a descrição dos casos de uso, e os desenvolvedores e clientes utilizam isto como acordo sobre o que o sistema deverá fazer.
Abrangem apenas a parte de interface e funcionalidades.
Modelo de use case
Especificação de use case
Ivar Jacobson, Object Oriented Software Engineering. Addison-Wesley / ACM Press. 1992
Processo de Engenharia de Requisitos
Página 30
Nome Descrição Restrição ProdutoGerado Referência Workshop de requisitos
O que é? É um framework para aplicar outras técnicas de elicitação de requisitos, tais como brainstorming e revisão de requisitos.
Porque utilizar? Porque pode-se ter todos os stakeholders focados e reunidos e pode-se ganhar tempo na priorização e validação dos requisitos coletados.
Quando se aplica? Na definição, especificação e validação de requisitos de uma aplicação: para a equipe conhecer os stakeholders, para ter uma “lista de desejos” dos stakeholders do projeto e para priorizar os requisitos coletados.
Como se usa?
• Deve-se fazer a preparação para o workshop onde será definido o analista que agirá como um facilitador e será enviado préviamente o material para os participates,;
• realizar a reunião (dar a todos a oportunidade de falar, manter o foco, coletar dados para definir atribuitos dos requisitos, registrar os pontos em aberto, sumarizar a sessão e realizar as conclusões) – de acordo com a técnica escolhida;
• consolidar os resultados depois da reunião (o facilitador resume e formata informações de forma apresentável)
Nem sempre é possível ter todos os stakeholders em um reunião.
Lista de requisitos desejados e priorizados
Work Guidelines: Requirements Workshop – RUP - Rational
Processo de Engenharia de Requisitos
Página 31
3.9. Formulários Formulário 1 - Documento de Visão
Página 32
DDOOCCUUMMEENNTTOO DDEE VVIISSÃÃOO ((RReeqquuiissiittooss))
IINNFFOORRMMAAÇÇÕÕEESS DDOO PPRROOJJEETTOO
CCÓÓDDIIGGOO::
NNOOMMEE::
GGEERREENNTTEE DDOO PPRROOJJEETTOO::
LLÍÍDDEERR DDOO PPRROOJJEETTOO::
SSOOLLIICCIITTAANNTTEE::
DDAATTAA SSOOLLIICCIITTAAÇÇÃÃOO::
Processo de Engenharia de Requisitos
Página 33
CONTROLE DE MUDANÇA E VERSÃO
VERSÃO DATA MUDANÇA RESPONSÁVEL REVISOR
Processo de Engenharia de Requisitos
Página 34
AApprroovvaaççããoo
Data: ____/____/_____. Analista de Negócio
Data: ____/____/_____. Usuário Final
Data: ____/____/_____. Coordenador de Desenvolvimento
Data: ____/____/_____. Gerente de Projeto
Processo de Engenharia de Requisitos
Página 35
Índice
1. PROPÓSITO DO DOCUMENTO....................................................................................................... 36
2. VISÃO DO NEGÓCIO ...................................................................................................................... 36
3. DESCRIÇÃO DO PROBLEMA ......................................................................................................... 36
4. STAKEHOLDER .............................................................................................................................. 36
4.1. LISTA DE STAKEHOLDERS ............................................................................................................... 36
5. VISÃO DO SISTEMA ....................................................................................................................... 36
5.1. DESCRIÇÃO DO SISTEMA/PROCESSO ATUAL ...................................................................................... 36 5.2. ESCOPO DO SISTEMA PROPOSTO ...................................................................................................... 36 5.3. OBJETIVO DO SISTEMA PROPOSTO.................................................................................................... 36 5.4. BENEFÍCIO DO SISTEMA PARA O NEGÓCIO ......................................................................................... 36 5.5. INTERFACES DO SISTEMA ................................................................................................................ 36 5.6. REQUISITOS FUNCIONAIS ................................................................................................................ 36
5.6.1. Solicitação 1 (R1) ................................................................ ................................................... 36 5.6.2. Solicitação n (Rn) ................................................................ ................................................... 36
5.7. REQUISITOS SUPLEMENTARES ......................................................................................................... 36 Requisitos de Conversão ..................................................................................................................... 37 Requisitos de Recuperação /Contingência ............................................................................................. 37 Requisitos de Segurança...................................................................................................................... 37 Requisitos de Controle /Acesso / Licença / Instalação ............................................................................ 37 Requisitos de Auditoria ....................................................................................................................... 37 Requisitos de Hardware ...................................................................................................................... 37 Requisitos de Software ........................................................................................................................ 37 Requisitos de Usabilidade ................................................................ ................................................... 37 Requisitos de Portabilidade ................................................................................................................. 37 Requisitos de Manutenibilidade ........................................................................................................... 37 Requisitos de Suportabilidade.............................................................................................................. 37 Requisitos de Performance .................................................................................................................. 37
5.8. CRITÉRIOS DE ACEITAÇÃO .............................................................................................................. 38 5.9. REQUISITOS LEVANTADOS E NÃO CONTEMPLADOS ............................................................................ 38 5.10. REGULAMENTAÇÕES E REGRAS DE NEGÓCIO .................................................................................. 38 5.11. TECNOLOGIA – REGRAS, LIMITAÇÕES E PADRÕES ........................................................................... 38 5.12. RESTRIÇÕES GENÉRICAS .............................................................................................................. 38
6. PREMISSAS ................................ ..................................................................................................... 38
7. FATORES DE RISCO ....................................................................................................................... 38
Processo de Engenharia de Requisitos
Página 36
1. Propósito do Documento
2. Visão do Negócio
3. Descrição do Problema Descrição do Problema
Afetados pelo Problema
Conseqüências
4. Stakeholder
4.1. Lista de Stakeholders
5. Visão do Sistema
5.1. Descrição do Sistema/Processo Atual
5.2. Escopo do Sistema Proposto
5.3. Objetivo do Sistema Proposto
5.4. Benefício do Sistema para o Negócio
5.5. Interfaces do Sistema
5.6. Requisitos Funcionais Solicitação 1 (R1)
SSttaakkeehhoo llddeerr:
FFuunncciioonnaall iiddaaddeess:
§ R1.1: § R1.2:
§ R1.n:
RReesstt rr iiççõõeess EEssppeeccíí ff ii ccaass:
Solicitação n (Rn)
SSttaakkeehhoo llddeerr:
FFuunncciioonnaall iiddaaddeess:
§ Rn.1: § Rn.2:
§ Rn.m:
RReesstt rr iiççõõeess EEssppeeccíí ff ii ccaass:
5.7. Requisitos Suplementares
Processo de Engenharia de Requisitos
Página 37
RReeqquuiiss ii ttooss ddee CCoonnvveerrssããoo Stakeholder:
Descrição do Requisito: Restrições Específicas:
RReeqquuiiss ii ttooss ddee RReeccuuppeerraaççããoo //CCoonntt iinnggêênncciiaa Stakeholder:
Descrição do Requisito: Restrições Específicas:
RReeqquuiiss ii ttooss ddee SSeegguurraannççaa Stakeholder: Descrição do Requisito:
Restrições Específicas:
RReeqquuiiss ii ttooss ddee CCoonnttrroollee //AAcceessssoo // LLiicceennççaa // IInnssttaa llaaççããoo Stakeholder: Descrição do Requisito:
Restrições Específicas:
RReeqquuiiss ii ttooss ddee AAuuddii ttoorriiaa Stakeholder:
Descrição do Requisito:
Restrições Específicas:
RReeqquuiiss ii ttooss ddee HHaarrddwwaarree Stakeholder:
Descrição do Requisito:
Restrições Específicas:
RReeqquuiiss ii ttooss ddee SSooffttwwaarree Stakeholder:
Descrição do Requisito:
Restrições Específicas:
RReeqquuiiss ii ttooss ddee UUssaabbiill iiddaaddee Stakeholder:
Descrição do Requisito: Restrições Específicas:
RReeqquuiiss ii ttooss ddee PPoorrttaabbii lliiddaaddee Stakeholder:
Descrição do Requisito: Restrições Específicas:
RReeqquuiiss ii ttooss ddee MMaannuutteenniibbiill iiddaaddee Stakeholder:
Descrição do Requisito: Restrições Específicas:
RReeqquuiiss ii ttooss ddee SSuuppoorrttaabbii lliiddaaddee Stakeholder: Descrição do Requisito:
Restrições Específicas:
RReeqquuiiss ii ttooss ddee PPeerrffoorrmmaannccee Stakeholder: Descrição do Requisito:
Restrições Específicas:
Processo de Engenharia de Requisitos
Página 38
5.8. Critérios de Aceitação
5.9. Requisitos Levantados e Não Contemplados
5.10. Regulamentações e Regras de Negócio
5.11. Tecnologia – Regras, Limitações e Padrões
5.12. Restrições Genéricas
6. Premissas
7. Fatores de Risco
8. Oportunidades
Processo de Engenharia de Requisitos
Página 39
Formulário 2 - Glossário
Página 40
GGLLOOSSSSÁÁRRIIOO
IINNFFOORRMMAAÇÇÕÕEESS DDOO PPRROOJJEETTOO
CCÓÓDDIIGGOO::
NNOOMMEE::
GGEERR EENNTTEE DD EE PPRROOJJEETTOO::
LLÍÍDDEERR DDEE PPRROOJJEETTOO::
Processo de Engenharia de Requisitos
Página 41
CONTROLE DE MUDANÇA E VERSÃO
VERSÃO DATA MUDANÇA RESPONSÁVEL REVISOR
Processo de Engenharia de Requisitos
Página 42
1. Introdução Este documento é utilizado para definir a terminologia específica do domínio do Sistema <Nome do Sistema>. Ele pode ser considerado como um dicionário informal de termos acordados com todos os envolvidos na definição do Sistema.
2. Definições Terno Definição
