TCC 2011 CBCC-UFPA Thiago

UNIVERSIDADE FEDERAL DO PAR
INSTITUTO DE CINCIAS EXATAS E NATURAIS

FACULDADE DE COMPUTAO
CURSO DE BACHARELADO EM CINCIA DA COMPUTAO

Thiago Jorge Almeida dos Santos

UM MECANISMO PARA MODELAGEM E EXECUO DE
ATIVIDADES PERIDICAS NO AMBIENTE WEBAPSEE

Belm
2011



ATIVIDADES PERIDICAS NO AMBIENTE WEBAPSEE

Trabalho de Concluso de Curso apresentado
para obteno do grau de Bacharel em Cincia da
Computao. Instituto de Cincias Exatas e
Naturais. Faculdade de Computao.
Universidade Federal do Par.

Orientador: Prof. Dr. Rodrigo Quites Reis

Belm
2011



ATIVIDADES PERIODICAS NO AMBIENTE WEBAPSEE

Trabalho de Concluso de Curso apresentado
para obteno do grau de Bacharel em Cincia da
Computao. Instituto de Cincias Exatas e
Naturais. Faculdade de Computao.
Universidade Federal do Par.

Data da defesa: 14/12/2011 11h10min
Conceito: BOM

Banca Examinadora

Pro. Dr. Rodrigo Quites Reis
Faculdade de Computao/UFPA Orientador

Prof. Dr. Benedito de Jesus Pinheiro Ferreira
Faculdade de Computao/UFPA Membro

Prof. Msc. Ernani de Oliveira Sales
Faculdade de Computao/UFPA Membro

minha famlia.
AGRADECIMENTOS
Agradeo a Deus, por ter me permitido concluir mais uma etapa importante da minha
vida, ter me dado fora para vencer desafios e superar obstculos, me permitido chegar at
aqui e aberto caminhos para que eu possa ir mais longe. E o mais importante, ter me permitido
fazer amigos, me divertir e aprender muitas coisas para a vida.
Obrigado, Tia, Jorge, Salim e Nathlia
, por terem me suportado e acompanhado de

perto as partes complicadas do caminho, e por todos os gestos de amor, compreenso e ajuda
recebidos. Agradeo a todos os meus familiares e amigos e todos aqueles que um dia
dividiram comigo um sorriso.
todos aqueles que escutaram meus desabafos e me incentivaram de alguma forma
todas as vezes quando o trabalho tornou-se pesado e at mesmo insuportveis para que um s
corao suportasse, saibam que sempre me senti mais feliz e motivado quando escutei um v
em frente e nunca desista. Todas as oraes, palavras de apoio e incentivo recebidas,
agradeo-as todas e desejo que bnos e felicidades sejam lanadas a quem torceu por mim e
me desejou a graa de poder completar essa parte do caminho.
Agradeo a meu orientador, prof. Dr. Rodrigo Quites Reis, pelos incentivos, puxes de
orelha e todo o tempo, esforo, apoio e ateno dispensados para a concluso desse trabalho.
E a todos os membros do LABES-UFPA e pela sorte que tive de participar desse grupo de
pesquisa, muito bom estar com vocs, eu no imaginava que sera to legal fazer parte.
Agradeo a cada professor que durante o curso de graduao contribuiu para o nosso
aprendizado e formao, saibam que vocs so muito importantes e sempre sero lembrados
pelos seus alunos. Tratem os alunos sempre com pacincia, lembrem-se que eles esto
aprendendo e todos sempre estamos e que ficamos velhos e o novo sempre vem.
Enfim, agradeo a todos aqueles que, eu tendo entrado em contato ou no, tenhamos
vivido uma mesma poca ou no, tenhamos concordado ou no, conectamos idias,
sentimentos, e que contriburam para minha formao. Todos vocs so importantes pra mim
e sempre considerados em grande medida. Desejo a todos amor, sade e felicidades.
Obrigado.

A felicidade s verdadeira quando compartilhada.
(Christopher J. McCandless)
SUMRIO
LISTA DE FIGURAS ............................................................................................................................................ 9
LISTA DE TABELAS ...........................................................................................................................................11
LISTA DE SIGLAS ..............................................................................................................................................13
RESUMO .........................................................................................................................................................14
ABSTRACT .......................................................................................................................................................15
1. INTRODUO .........................................................................................................................................16
1.1. Contexto do Trabalho ........................................................................................................................... 17
1.2. Motivao ............................................................................................................................................ 19
1.3. Justificativa .......................................................................................................................................... 19
1.4. Objetivos do Trabalho .......................................................................................................................... 20
1.5. Organizao do Texto .......................................................................................................................... 20
2. APOIO MODELAGEM E EXECUO DE PROCESSOS ..............................................................................21
2.1. Processo de Software Orientado a Atividades ..................................................................................... 23
2.1.1. Ciclo de Vida e Modelos de Processos de Software .................................................................... 24
2.1.2. Modelagem de Processo de Software ......................................................................................... 26
2.1.3. Execuo de Processo de Software ............................................................................................. 26
2.2. Atividades Peridicas ........................................................................................................................... 31
2.3. Consideraes Finais do Captulo ......................................................................................................... 33
3. O AMBIENTE WEBAPSEE .........................................................................................................................34
3.1. Arquitetura Geral ................................................................................................................................. 35
3.1.1. ManagerConsole ......................................................................................................................... 36
3.1.2. TaskAgenda ................................................................................................................................. 37
3.2. Linguagem de Modelagem de Processos ............................................................................................. 38
3.3. Mquina de Execuo .......................................................................................................................... 41
3.3.1. Gramticas de Grafos .................................................................................................................. 42
3.3.2. Regras da Mquina de Execuo ................................................................................................. 42
3.4. Consideraes Finais do Captulo ......................................................................................................... 45
4. PROPOSTA DE UM MECANISMO PARA A UTILIZAO DE ATIVIDADES PERIDICAS NO AMBIENTE
WEBAPSEE ......................................................................................................................................................46
8

4.1. Viso Geral ........................................................................................................................................... 47
4.2. Consideraes Iniciais .......................................................................................................................... 48
4.2.1. Decises de Projeto ..................................................................................................................... 50
4.2.2. Formalismos Utilizados ............................................................................................................... 52
4.3. Exemplo da Utilizao de Atividades Peridicas no Mecanismo Proposto .......................................... 53
4.4. Caracterizao das Atividades Peridicas ............................................................................................ 59
4.4.1. Definies .................................................................................................................................... 61
4.4.2. Tipos de Atividades Peridicas .................................................................................................... 64
4.4.3. Requisitos .................................................................................................................................... 65
4.4.4. Casos de Uso ............................................................................................................................... 67
4.5. Extenso da WebAPSEE-PML .............................................................................................................. 78
4.6. Execuo das Atividades Peridicas ..................................................................................................... 81
4.7. Regras Para a Mquina de Execuo ................................................................................................... 86
4.8. Modelo de Dados ................................................................................................................................. 88
4.9. Interao Com o Usurio ..................................................................................................................... 88
4.9.1. Manager Console ........................................................................................................................ 89
4.10. Trabalhos Correlatos ............................................................................................................................ 93
4.10.1. Microsoft Project Professional 2010 ........................................................................................... 95
4.10.2. Oracle BPEL Process Manager ..................................................................................................... 99
4.11. Consideraes Finais do Captulo ....................................................................................................... 101
5. CONCLUSES ........................................................................................................................................ 103
5.1. Contribuies ..................................................................................................................................... 103
5.2. Limitaes do Trabalho ...................................................................................................................... 103
5.3. Trabalhos Futuros .............................................................................................................................. 104
5.4. Consideraes Finais .......................................................................................................................... 105
REFERNCIAS BIBLIOGRFICAS ..................................................................................................................... 106
APNDICE A Prottipos de Formulrios ...................................................................................................... 113
APNDICE B Regras Para A Mquina de Execuo ...................................................................................... 129

9

LISTA DE FIGURAS
Figura 2.1 O Modelo Cascata de Processo.......................................................................................................... 25
Figura 2.2 Interaes entre o mecanismo de execuo e outros componentes do PSEE. ................................. 28
Figura 3.1 Viso arquitetural em camadas do ambiente WebAPSEE. ................................................................ 36
Figura 3.2 Viso do gerente no WebAPSEE: componente Manager Console e sua PML grfica........................ 37
Figura 3.3 TaskAgenda do WebAPSEE. ............................................................................................................... 38
Figura 3.4 Notao da WebAPSEE-PML para modelagem de processos. ........................................................... 39
Figura 3.5 Grafo-tipo da WebAPSEE-PML. .......................................................................................................... 40
Figura 3.6 Grafo-tipo usado para semntica da execuo no WebAPSEE. ......................................................... 43
Figura 3.7 Regra para incluso de nova atividade em um processo................................................................... 44
Figura 4.1 (1) Projeto que utiliza o processo de medio; (A), (B) e (C) Atividades decompostas nas quais foi
aplicado o processo de medio (contido em I, II e III). ........................................................................................ 54
Figura 4.2 Cada execuo do processo de medio nas atividades da Figura 4.1. ............................................. 56
Figura 4.3 Utilizao da Atividade Peridica para implementar o processo de Medio. ................................. 58
Figura 4.4 Casos de uso gerais para atividades peridicas. ................................................................................ 68
Figura 4.5 Casos de uso especficos para atividades peridicas. ........................................................................ 69
Figura 4.6 Grafo-tipo do modelo sinttico da WebAPSEE-PML (trecho). ........................................................... 79
Figura 4.7 Atividades peridicas e elementos relacionados inseridos no grafo-tipo do modelo sinttico da
WebAPSEE-PML (trecho). ...................................................................................................................................... 80
Figura 4.8 Atividades peridicas e elementos relacionados inseridos no grafo-tipo do modelo sinttico da
WebAPSEE-PML (trecho). ...................................................................................................................................... 81
Figura 4.9 Transio de estados de perodos. .................................................................................................... 82
Figura 4.10 Transio de estados de atividades peridicas. ............................................................................... 83
Figura 4.11 Diagrama de como o sistema gerencia a execuo de perodos. .................................................... 85
Figura 4.12 Regra para incluso de nova atividade em um processo. ............................................................... 87
10

Figura 4.13 Representao da atividade peridica no ManagerConsole. .......................................................... 89
Figura 4.14 Prottipo de formulrio para a configurao de atividades peridicas regulares para o
ManagerConsole. .................................................................................................................................................. 91
Figura 4.15 Tela principal do Microsoft Project Professional 2010. ................................................................... 96
Figura 4.16 Opo para insero de atividades peridicas no Microsoft Project Professional 2010. ................ 97
Figura 4.17 Configurao de atividades peridicas no Microsoft Project Professional 2010. ........................... 98
Figura 4.18 Tela do JDeveloper mostrando um processo modelado utilizando a linguagem WS-BPEL. .......... 100

11

LISTA DE TABELAS
Tabela 1 Requisitos de execuo de processos. Adaptado de (LIMA REIS, 2003). ......................................... 29
Tabela 2 Grupos de regras existentes no WebAPSEE e grupos que pertencem ao escopo. ........................... 51
Tabela 3 Requisitos funcionais para atividades peridicas. ........................................................................... 65
Tabela 4 Caso de Uso Geral 1. Gerenciar Atividade Peridica. ...................................................................... 70
Tabela 4.1 Caso de Uso 1.1. Criar Nova Atividade Peridica. ........................................................................ 70
Tabela 4.2 Caso de Uso 1.2. Tornar Peridica uma Atividade No-Peridica. ............................................... 70
Tabela 4.3 Caso de Uso 1.3. Configurar Atividade Peridica. ........................................................................ 70
Tabela 4.4 Caso de Uso 1.4. Excluir Atividade Peridica. ............................................................................... 71
Tabela 4.5 Caso de Uso 1.5. Cancelar Atividade Peridica............................................................................. 71
Tabela 4.6 Caso de Uso 1.6. Falhar Atividade Peridica. ............................................................................... 71
Tabela 4.7 Caso de Uso 1.7. Consultar Atividade Peridica. .......................................................................... 71
Tabela 5 Caso de Uso Geral 2. Gerenciar Perodos. ....................................................................................... 72
Tabela 5.1 Caso de Uso 2.1. Adicionar Perodo. ............................................................................................. 72
Tabela 5.2 Caso de Uso 2.2. Configurar Perodos. .......................................................................................... 72
Tabela 5.3 Caso de Uso 2.3. Remover Perodo. .............................................................................................. 73
Tabela 5.4 Caso de Uso 2.4. Falhar Perodo. .................................................................................................. 73
Tabela 5.5 Caso de Uso 2.5. Cancelar Perodo. .............................................................................................. 73
Tabela 5.6 Caso de Uso 2.6. Consultar Perodos. ........................................................................................... 73
Tabela 6 Caso de Uso Geral 3. Gerenciar Prazos. ........................................................................................... 74
Tabela 6.1 Caso de Uso 3.1. Criar Prazo. ........................................................................................................ 74
Tabela 6.2 Caso de Uso 3.2. Configurar Prazos. ............................................................................................. 74
Tabela 6.3 Caso de Uso 3.3. Remover Prazo. ................................................................................................. 74
Tabela 6.4 Caso de Uso 3.4. Consultar Prazos. ............................................................................................... 75
Tabela 7 Caso de Uso Geral 4. Gerenciar Marcos. ......................................................................................... 75
Tabela 7.1 Caso de Uso 4.1. Criar Marco. ...................................................................................................... 75
Tabela 7.2 Caso de Uso 4.2. Configurar Marco. ............................................................................................. 75
Tabela 7.3 Caso de Uso 4.3. Remover Marco. ................................................................................................ 76
Tabela 7.4 Caso de Uso 4.4. Consultar Marcos. ............................................................................................. 76
Tabela 8 Caso de Uso Geral 5. Fornecer Feedback da Tarefa Realizada. ....................................................... 76
12

Tabela 9 Matriz de relacionamento Casos de Uso x Requisitos Funcionais. .................................................. 77

13

LISTA DE SIGLAS

ADS Ambiente de Desenvolvimento de Software
CMMI Capability Maturity Model Integration
MPS-BR Programa para Melhoria do Processo de Software Brasileiro
OMG Object Management Group
PML Process Modeling Language
PSEE Process-centered Software Engineering Environment
SEI Software Engineering Institute, from Carnegie Mellon University
SOFTEX Associao para a Promoo da Excelncia do Software Brasileiro
SPEM Software & Systems Process Engineering Metamodel specification

14

RESUMO
Sistemas de software esto presentes atualmente em todos os lugares e atividades
desempenhadas com ou sem interveno humana, assumindo papis decisivos para o alcance
de objetivos de negcios e agregando valor aos produtos e servios. Em razo da estreita
relao entre a qualidade do software e o processo utilizado em seu desenvolvimento,
esforos foram e esto sendo realizados para a melhoria dos processos de software utilizados
e para a construo de ferramentas e ambientes computacionais que auxiliem no processo.
Neste sentido, dentro da rea de pesquisa intitulada Tecnologia de Processo de Software,
surgiram os ambientes de desenvolvimento de software orientados ao processo ou PSEEs
(Process-centered Software Engineering Environment) permitindo auxlio modelagem e
execuo de processos de software.
Durante o processo de desenvolvimento de software algumas atividades precisam ser
realizadas vrias vezes em perodos de tempo pr-determinados. Dentre elas, as atividades
conhecidas como guarda-chuva ocorrem de forma transversal durante o processo, so
recorrentes e aplicveis durante todo o processo, focalizando principalmente a gesto, o
monitoramento e o controle do projeto; essas atividades so atividades peridicas, pois
ocorrem em perodos de tempo pr-determinados visando um objetivo bem definido.
Este trabalho prope um mecanismo para a modelagem e execuo de atividades
peridicas no ambiente WebAPSEE, PSEE desenvolvido pelo Laboratrio de Engenharia de
Software da UFPA. Espera-se contribuir com a automao do controle de perodos de
execuo, contribuir com a diminuio do esforo por parte de gerentes de processo/projeto
no desempenho de parte de suas atividades e garantir a conformidade com modelos de
processo. Este trabalho pretende inserir no WebAPSEE uma abordagem prevista na literatura
como caracterstica de algumas atividades que ocorrem durante o processo de software que,
porm, no implementada de forma satisfatria pela tecnologia atual, que invariavelmente
trata o problema com simples repeties ou demandam um esforo muito grande por parte do
gerente de projetos/processos para alcanar o mesmo resultado.

PALAVRAS-CHAVE: Tecnologia de Processo de Software, Ambiente de Desenvolvimento
de Software Centrado em Processos, WebAPSEE, Atividades Peridicas.
15

ABSTRACT
Software systems are present in all places and activities performed with or without human
intervention, assuming key roles for the achievement of business objectives and adding value
to products and services. Because of the close relationship between software quality and the
process used in its development, efforts have been done for the improvement of software
processes and the development of computational tools and environments that can give support
in the process. In this sense, within the research area called Software Process Technology,
were created the Process-centered Software Engineering Environments or PSEEs, allowing
aid to the modeling and execution of software processes.
During the software development process some activities must be performed several times
in pre-determined periods of time. Among them, the activities known as umbrella activity
transversely occur during the process, are recurring and applicable throughout the process and
focus mainly on the management, monitoring and control of the project; these activities are
periodic activities because they occur in predetermined time periods ordering a well-defined
objective.
This paper proposes a mechanism for modeling and execution of periodic activities in the
WebAPSEE environment, a PSEE developed by the Software Engineering Laboratory of
UFPA. Focusing on providing the automated control for periods enactment, aiming to
contribute to reduce the effort by process/project managers in the performance of part of its
activities and ensure compliance with process models. This work intends to implement into
the WebAPSEE a literature approach as characteristic of some activities that occur during the
software process, however, not implemented satisfactorily by other environments, invariably
dealing the problem with simple repetitions or require a great effort by the project/process
manager to achieve the same result.

KEYWORDS: Software Process Technology, Process-centered Software Engineering
Environment, WebAPSEE, Periodic Activities.

16

1. INTRODUO
Atualmente, os sistemas de software esto presentes em todos os lugares e atividades
desempenhadas com ou sem interveno humana, seja em atividades simples como enviar
mensagens de texto a um amigo ou tarefas delicadas como monitorar e gerenciar o trfego
areo de uma metrpole, tornando-se no mais apenas um acessrio para o desempenho de
tarefas humanas, mas elemento principal, indispensvel para o alcance de objetivos de
negcios e agregando valor aos produtos e servios.
A qualidade do software produzido est relacionada qualidade do processo utilizado em
seu desenvolvimento (CONRADI; FERNSTRM; FUGGETTA, 1994; ARBAOUI et al.,
2002; ABNT, 2003). Dada essa estreita relao, inmeros pesquisadores e profissionais
direcionaram estudos para a melhoria dos processos por meio dos quais o software
desenvolvido (FUGGETTA, 2000).
Muitos programas para a melhoria do processo de desenvolvimento de software surgiram,
comearam a ser difundidos e adotados por muitas organizaes. So exemplos de modelos
para a melhoria de processos o modelo CMMI (SEI, 2010) e o modelo MPS (SOFTEX,
2011). O modelo MPS um modelo brasileiro que vem sendo utilizado cada vez mais pelas
empresas brasileiras. Visando acompanhar e avaliar o desempenho das empresas que adotam
o modelo MPS, o projeto iMPS (TRAVASSOS; KALINOWSKY, 2010) vem divulgando
resultados desde 2008. Sua ltima verso, publicada em 2010, apresenta os resultados da
pesquisa iMPS 2010 e avalia o desempenho de empresas que adotaram o modelo MPS de
2008 a 2010. Essas pesquisas mostram, a partir de anlise de desempenho de empresas que
adotam o modelo MPS, que as empresas tendem a apresentar os benefcios esperados em
relao a custo, prazo, produtividade e qualidade quando adotam iniciativas de melhoria de
17

processo de software de acordo com as boas prticas de engenharia de software encontradas
na literatura (TRAVASSOS; KALINOWSKY, 2010).
1.1. Contexto do Trabalho
Mediante a demanda de sistemas cada vez mais complexos e a complexidade inerente ao
processo de desenvolvimento, um auxlio execuo desse processo que pudesse lhe garantir
qualidade e, consequentemente, qualidade ao produto mostrou-se necessrio. Estudos
mostram que iniciativas de automao do processo de desenvolvimento de software so
seguidas de grandes benefcios econmicos para as organizaes (FUGGETA; WOLF, 1996).
Nesse contexto, uma das reas de maior destaque a rea conhecida como Tecnologia de
Processos de Software, que envolve a construo de ferramentas e ambientes
computadorizados para a modelagem, execuo
1
, simulao e evoluo de processos de
desenvolvimento de software (LIMA REIS, 2003). Dentre as principais ferramentas
desenvolvidas em decorrncia de pesquisas nesta rea esto os ambientes de desenvolvimento
de software (ADS) orientados ao processo ou PSEEs (Process-centered Software Engineering
Environments), ambientes que permitem a modelagem e execuo de processos de software
(FUGGETTA, 2000).
Devido ao grande nmero de variveis associadas ao processo de desenvolvimento de
software, os PSEEs devem lidar da melhor forma com esses diversos elementos e
caractersticas do processo de software visando apoiar adequadamente o desenvolvimento.
Entretanto, a tecnologia existente possui limitaes, sendo uma das principais a falta de
flexibilidade (FUGGETTA, 2000; ARBAOUI et al., 2002; LIMA REIS, 2003), alm do no
atendimento de caractersticas importantes de processos de software.
O processo de desenvolvimento de software possui caractersticas prprias, diferentes de
outros tipos de processo. Diversos elementos surgem no decorrer do processo (pessoas,
metodologias, artefatos, ferramentas, relatrios, estimativas, contratos, prazos, custos e outros
recursos) e interferem de diferentes formas medida que vo sendo inseridos no processo. A
alta variabilidade e imprevisibilidade desse processo, ocasionadas principalmente pelo

1
Segundo (LIMA REIS, 2003) e (SOUSA et al., 2001), o termo utilizado mais frequentemente na literatura
process enactment, que significa que o processo no ser totalmente automatizado como sugere o termo
execuo, mas executado por pessoas e mquinas, porm, o termo execuo mais utilizado na literatura
nacional. Neste trabalho ser utilizado o termo execuo com o sentido de enaction.
18

envolvimento de pessoas desenvolvendo tarefas criativas e interagindo entre si e com as
ferramentas que apoiam suas atividades, aumenta ainda mais a complexidade do processo.
Nesse contexto, vrias atividades podem ser realizadas durante o processo de
desenvolvimento de software com o objetivo de se construir o produto de software requerido.
Dentre essas atividades, existe um grupo de atividades conhecido como atividades peridicas.
Estas atividades ocorrem por vrias vezes e em vrios momentos durante o processo de
software, em perodos regulares ou variveis, e podem ser associadas com o conceito de
atividades guarda-chuva ou atividades de apoio (PRESSMAN, 2006; 2011). Tais atividades
so muito importantes durante todo o processo, principalmente por serem atividades que
auxiliam no gerenciamento, monitoramento e controle do projeto. Nesse contexto,
ferramentas que tem como objetivo apoiar a modelagem e execuo de processos de
desenvolvimento de software devem permitir a representao adequada dos elementos
envolvidos no processo, dentre eles as atividades guarda-chuva e tambm as atividades
peridicas.
Inserido na categoria dos PSEEs, o WebAPSEE (LIMA et al., 2006) um ambiente para a
gesto de processos de software, baseado no modelo APSEE proposto por (LIMA REIS,
2003). O ambiente WebAPSEE permite a modelagem, execuo e acompanhamento de
processos por meio de uma Linguagem de Modelagem de Processos (PML, Process
Modelling Language) grfica e est em constante processo de melhoria e integrao de novas
funcionalidades. Alm de facilitar a reutilizao de boas prticas gerenciais por diferentes
projetos e a coordenao de atividades de equipes dispersas geograficamente; considerar
aspectos organizacionais; permitir modificaes durante a execuo do processo e a interao
entre seus participantes; o WebAPSEE apoia, de forma integrada, a gerao de relatrios de
acompanhamento, gerncia de requisitos, reutilizao de processos, gerncia de configurao
de artefatos, medio e estimativas, gerncia de conhecimento, alocao de recursos humanos
e definio de polticas de alocao de recursos (LIMA REIS, 2003; SALES, M., 2008;
COSTA; SALES, E., 2007; COSTA, 2010; SILVA, A., 2008; SALES, E., 2009;
NASCIMENO, 2007; OLIVEIRA, 2010; SILVA, M., 2007). Atualmente, em sua verso 1.8,
o WebAPSEE ainda no apoia a utilizao de atividades peridicas definidas formalmente
durante o processo de desenvolvimento.

19

1.2. Motivao
Durante a modelagem e execuo do processo de software, a definio de atividades
peridicas pode ser de grande importncia para o gerenciamento, monitoramento e controle
do projeto. Entretanto, atualmente, para modelar essas atividades no processo de software,
mesmo com a ajuda de ferramentas de modelagem, necessrio um grande esforo repetitivo
por parte do gerente de processos, pois difcil se encontrar um tratamento direcionado a esse
grupo de atividades e que facilite sua definio e controle nas ferramentas existentes.
Como as atividades peridicas ocorrem por vrias vezes e em diferentes momentos do
processo, necessrio que o gerente planeje vrias vezes uma atividade desse tipo, sendo
uma vez para cada momento em que a atividade deve ser realizada no decorrer do processo.
Se ela aparecer dez vezes em pontos diferentes do processo, por dez vezes o gerente deve
inseri-las nos pontos especficos de ocorrncia. Um exemplo de atividade peridica a
gerao de releases em um modelo de processo incremental, que deve ocorrer ao final de cada
incremento. Para se planejar cada release realiza-se um esforo repetitivo. Adicionalmente,
esse trabalho se torna mais dispendioso em processos grandes e complexos com vrios nveis
de sub-processos, dificultando, por exemplo, o monitoramento do andamento dessas
atividades, estando elas dispersas no processo.
Desenvolver um mecanismo que de forma automatizada auxilie a insero e
monitoramento dessas atividades peridicas durante a execuo do processo de software tem
o potencial de diminuir esse esforo repetitivo por parte do gerente de processos/projetos.
Alm disso, tratar essas atividades de forma especializada em uma ferramenta PSEE pode ser
de grande valia, visto que, de forma geral, no h um tratamento direcionado a esse grupo de
atividades nas ferramentas existentes, apesar de elas serem previstas na literatura e de sua
importncia para o processo de desenvolvimento de software.
1.3. Justificativa
Muitos trabalhos tm sido realizados objetivando a melhoria do ambiente WebAPSEE, o
que tem contribudo bastante para o seu desenvolvimento desde que foi concebido no trabalho
de doutorado de (LIMA REIS, 2003), a partir da proposta da arquitetura APSEE.
O autor deste trabalho vem realizando h dois anos pesquisas de Iniciao Cientfica no
intuito de prover melhorias ao ambiente WebAPSEE. Nos resultados obtidos desses trabalhos
20

(SANTOS et al., 2010; 2011) foram feitos estudos com usurios e desenvolvedores do
componente Manager Console do WebAPSEE em busca de sugestes de melhoria para o
sistema na viso dos prprios usurios e desenvolvedores. Uma das sugestes indicadas como
possibilidade de melhoria do sistema foi a implementao de atividades peridicas no mesmo
devido o grande esforo necessrio atualmente para se modelar e monitorar essas atividades
no ambiente.
1.4. Objetivos do Trabalho
Dentro desse contexto apresentado como introduo, este trabalho pretende contribuir
para o desenvolvimento do WebAPSEE integrando ao ambiente um mecanismo para a
modelagem e execuo de atividades peridicas. As atividades peridicas so previstas na
literatura como caracterstica de algumas atividades que ocorrem durante processos de
software. Porm, elas no so implementadas de forma satisfatria por outros ambientes, que
tratam apenas simples repeties ou que necessitam de um esforo muito grande por parte do
gerente de projetos/processos para alcanar o mesmo resultado.
1.5. Organizao do Texto
De aqui em diante o texto se organiza da seguinte forma: no captulo 2 ser apresentada
uma introduo ao apoio modelagem e execuo de processos, abordando ciclos de vida e
modelos de processos de software, modelagem e execuo de processos de software e de
atividades peridicas. Em seguida, no captulo 3, ser apresentado o ambiente WebAPSEE,
arquitetura geral, a Linguagem de Modelagem de Processos (PML), a mquina de execuo e
como feita a definio de regras e os dois componentes que interagem diretamente com o
usurio, o Manager Console e a TaskAgenda.
No captulo 4, ser apresentado a proposta de mecanismo para a modelagem e execuo
de atividades peridicas integrado ao WebAPSEE, com algumas observaes e decises de
projeto, terminologias, requisitos e casos de uso das atividades peridicas, a viso geral da
proposta quanto execuo de atividades e perodos e como essa interao se d com os
usurios, finalizando com alguns trabalhos relacionados. Por fim, no captulo 5, ser
apresentada uma avaliao geral do trabalho, contribuies, limitaes, trabalhos futuros e
consideraes finais.
21

2. APOIO MODELAGEM E EXECUO DE PROCESSOS
A Engenharia de Software tambm se preocupa com os processos, mtodos e ferramentas
para o desenvolvimento de sistemas de software e de maneira rpida e econmica
(FINKELSTEIN; KRAMER, 2000). um ramo da engenharia de sistemas que est focado
em atender metas e necessidades reais, prover servios e nas restries de sistemas; ainda, na
especificao precisa da estrutura e comportamento do sistema bem como da implementao
dessas especificaes, nas atividades requeridas para se garantir que as especificaes e
objetivos foram alcanados e na evoluo desses sistemas atravs do tempo e de possveis
evolues. De forma geral, lidando com o desenvolvimento, avaliao e manuteno
sistemticos de software (ENDRES; ROMBACH, 2003).
Segundo a norma NBR ISO 10006:2000 (ABNT, 2000), processo o conjunto de
recursos e atividades inter-relacionadas que transformam insumos em resultados, ainda,
adicionado como nota: recursos podem incluir gerenciamento, servios, pessoal, finanas,
utilidades, equipamentos, tcnicas e mtodos e os processos do Projeto incluem os
processos de gerenciamento do Projeto.
Como mencionado na seo introdutria, dentro da rea de Tecnologia de Processo de
Software, ferramentas foram desenvolvidas no intuito de proporcionar apoio automatizado ao
processo (SOMMERVILLE, 2003). Uma das principais ferramentas de apoio ao
desenvolvimento de software ou ADS surgidas nesse contexto foram os PSEEs. Segundo
Nunes et al. (2004), PSEEs so ferramentas de trabalho de grande importncia para os
gerentes e desenvolvedores de software, pois os usurios desenvolvedores interagem com o
ambiente para obter orientao sobre o que fazer e prover feedback sobre o que foi feito,
enquanto que gerentes podem monitorar e coordenar o modelo de processo sendo executado.
22

De modo geral, os usurios dos PSEEs podem estar atuando em dois papis principais:
gerente e desenvolvedor. Gerente a denominao geral usada para designar aqueles que tm
como responsabilidade a monitorao, gerncia e manuteno do modelo de processo sendo
executado, enquanto o Desenvolvedor atua no desenvolvimento de software realizando
atividades que contribuem diretamente com a produo do mesmo. Ambos interagem com o
PSEE durante a execuo de um processo, porm possuem objetivos diferentes (LIMA REIS,
2003).
Apesar de todo o avano obtido, as ferramentas que apoiam o desenvolvimento de
software, de forma geral, ainda so incompletas e possuem limitaes. A definio e execuo
de atividades peridicas, por exemplo, no tratada de forma satisfatria pelas ferramentas
existentes, ocasionando um grande esforo por parte do gerente de processos/projeto para a
definio e controle dessas atividades durante o processo de desenvolvimento de software
sem o apoio adequado. Para tanto, o gerente necessita realizar tarefas repetitivas e gerenciar
essas atividades dispersas pelo processo.
Muitos modelos que estabelecem diretrizes para a modelagem e execuo de processos
surgiram procurando orientar gerentes de processo a como definir processos. O SPEM
(Software & Systems Process Engineering Meta-Model Specification) (OMG, 2008),
atualmente na verso 2.0, um modelo criado para definir software e processos de
desenvolvimento de sistemas e seus componentes. Seu objetivo acomodar um grande
nmero de mtodos de processos de desenvolvimento focando em prover informaes e
estruturas necessrias para se modelar processos aos engenheiros de processo. O SPEM,
entretanto, no fornece um apoio especfico definio de atividades peridicas, logo,
ferramentas que se baseiam exclusivamente nele tambm no oferecem apoio esse grupo de
atividades.
Cada processo pode ser descrito de vrias maneiras, utilizando texto, figuras ou uma
combinao desses recursos (PFLEEGER, 2004). O processo pode ser orientado a tarefas,
metas, documentos, tarefas e documentos, de acordo com a forma como o processo
visualizado (SOUSA et al., 2001). Processos orientados a documentos, por exemplo, tm
como elemento central os documentos consumidos e produzidos durante o processo, sendo
que o processo todo se desenvolve centrado no consumo e produo de documentao. Nos
processos de software orientados a metas, a visualizao do processo baseia-se em metas a
serem atingidas, sem distinguir as tarefas ou documentos. Processos de software orientados a
tarefas ou atividades consistem em processos de software onde as atividades so o principal
23

elemento do processo e a realizao de um conjunto de atividades que possuem um fluxo de
realizao e outros elementos que apoiam sua execuo.
Aps muitos anos de estudo por parte da comunidade de Cincia da Computao, pode-se
observar o impacto que numerosos avanos na Engenharia de Software tm trazido forma
como se produz software atualmente (ZELKOWIZ et al., 2005). notrio que o surgimento
de ferramentas que auxiliam o processo de desenvolvimento de software, de forma a procurar
diminuir a complexidade inerente ao processo de desenvolvimento e garantir qualidade ao
produto, sem as quais essa atividade, nos padres de exigncia e necessidades atuais, seria
mais que difcil, foi um dos grandes avanos na rea.
2.1. Processo de Software Orientado a Atividades
muito comum ferramentas apoiarem o processo de desenvolvimento de software
orientado a atividades, o ambiente WebAPSEE, por exemplo, utiliza essa abordagem.
Segundo (CONRADI et al., 1994), um processo de software um conjunto de atividades de
engenharia de software e informaes associadas necessrias para transformar os requisitos de
um usurio em um software funcional.
Um processo no uma prescrio rgida de como desenvolver software, pelo contrrio,
uma abordagem adaptvel - ao problema, ao projeto, equipe e cultura organizacional - que
possibilita equipe de software selecionar e escolher o conjunto apropriado de aes e tarefas
para cada projeto (PRESSMAN, 2011), permitir essa flexibilidade um requisito importante
em ambientes de desenvolvimento de software (LIMA REIS, 2003).
Um arcabouo de processo estabelece o alicerce para um processo de
software completo pela identificao de um pequeno nmero de atividades de
arcabouo aplicveis a todos os projetos de software, independentemente de
seu tamanho ou complexidade. Alm disso, o arcabouo de processo engloba
um conjunto de atividades guarda-chuva que so aplicveis durante todo o
processo de software. (PRESSMAN, 2006).
De acordo com Pressman (2006), o arcabouo descrito na viso genrica de engenharia de
software complementado por vrias atividades guarda-chuva. Estas atividades so atividades
peridicas, recorrentes e aplicveis de forma transversal durante todo o processo de
desenvolvimento, voltadas principalmente para o gerenciamento, monitoramento e controle
do projeto (PRESSMAN, 2006; 2011). Exemplos de atividades guarda-chuva tpicas so:
24

controle e acompanhamento do projeto, gesto de riscos, garantia de qualidade de software,
revises tcnicas, medio, gesto de configurao de software, reutilizao, preparo e
produo de artefatos de software.
Para finalizar, pode-se dizer, segundo (PRESSMAN, 2011), que processo um conjunto
de atividades, aes e tarefas realizadas na criao de algum produto de trabalho, onde: uma
atividade busca atingir um objetivo amplo (e.g., comunicar-se com os interessados
2
), utilizada
independentemente do campo de aplicao, tamanho, complexidade ou grau de exigncias do
projeto; uma ao (e.g., projeto de arquitetura) envolve um conjunto de tarefas que produzem
um artefato de software fundamental (e.g., modelo de projeto de arquitetura); e uma tarefa
concentra-se em um objetivo pequeno, mas bem definido (e.g., realizar um teste de unidade),
produzindo resultado tangvel.
Outras caractersticas de processos de software podem ser encontradas em (CONRADI;
FERNSTRM; FUGGETTA, 1994; CONRADI et al., 1994; GARG; JAZAYERI, 1996;
HUFF, 1996; LIMA REIS, 2003; PFLEEGER, 2004; PRESSMAN, 2006; SNOWDON;
WARBOYS, 1994; SOMMERVILLE, 2003).
2.1.1. Ciclo de Vida e Modelos de Processos de Software
Quando o processo envolve a elaborao de um produto, algumas vezes nos referimos a
eles como ciclo de vida. Assim, o processo de desenvolvimento de software pode ser
chamado de ciclo de vida do software (PFLEEGER, 2004).
Segundo (PFLEEGER, 2004), o desenvolvimento de software envolve os seguintes
estgios: Anlise e definio de requisitos; Projeto do sistema; Projeto do programa;
Programao; Teste de unidades; Teste de integrao; Teste do sistema; Entrega do sistema;
Manuteno. Cada estgio por si s um processo (ou coleo de processos) que pode ser
descrito como conjunto de atividades, cada uma envolvendo restries, resultados e recursos.
Segundo (SOMMERVILLE, 2003), todos os processos de software incluem: Especificao de
Software, Projeto e Implementao de Software, Validao de Software e Evoluo de
Software.

2
Interessado qualquer um que tenha interesse no sucesso de um projeto executivos, usurios finais,
engenheiros de software, desenvolvedores e etc. (PRESSMAN, 2011) seja um indivduo ou grupo, responsvel
ou afetado pelo produto de uma tarefa, atividade ou processo (SOFTEX, 2011). O termo utilizado no ingls
stakeholder, o qual pode ser eventualmente utilizado neste texto.
25

Muitos autores definem um conjunto de atividades ou tarefas necessrias a um processo
de desenvolvimento de software. Os modelos de processo de software so representaes
abstratas desses processos (SOMMERVILLE, 2003).
Modelos de processo genricos, chamados em (PRESSMAN, 2006) de processos
prescritivos, descrevem a organizao dos processos de software. Dentre os exemplos de
modelos genricos destacam-se o modelo cascata, o desenvolvimento evolucionrio, o
desenvolvimento formal de sistemas e o desenvolvimento orientado a reuso
(SOMMERVILLE, 2003). Na Figura 2.1 mostrado um exemplo de Modelo de Processo
prescritivo clssico, o Modelo Cascata.

Figura 2.1 O Modelo Cascata de Processo.
Cada modelo de processo representa um processo a partir de uma perspectiva particular,
proporcionando apenas informaes parciais sobre o processo. Alguns so descries do
caminho que o desenvolvimento de software deve seguir, outros so descries de como o
desenvolvimento de software realmente feito. Teoricamente, esses dois tipos de modelo
deveriam ser iguais ou semelhantes, mas na prtica no so (SOMMERVILLE, 2003).
Durante o ciclo de vida de um modelo de processo, vrios elementos aparecem e so
importantes para definir suas etapas ou fases. Os marcos so exemplos de um desses
elementos. Segundo o meta-modelo para definio de processos SPEM (OMG, 2008), um
marco (milestone) representa um evento significante em um projeto de desenvolvimento,
como uma deciso importante, concluso de um entregrvel, ou uma reunio importante (em
virtude da concluso de uma fase do projeto, por exemplo); comumente utilizado para
referenciar tanto o prprio evento e o ponto no tempo no qual o evento ocorreu ou foi
planejado para ocorrer.

26

2.1.2. Modelagem de Processo de Software
A Linguagem de Modelagem de Processos (Process Modeling Language PML) deve
permitir a definio do processo. Linguagens de modelagem de processos so diferentes de
outras linguagens computacionais porque a maioria dos fenmenos descritos devem ser
realizados por pessoas e no por mquinas (LIMA REIS, 2003). Representar os componentes
de um processo em uma modelagem necessrio no apenas para a execuo do processo
modelado, mas tambm para comunicar aos interessados o processo que est sendo seguido.
Os elementos do processo precisam ser descritos de alguma forma. Segundo (PFLEEGER,
2004), cada processo pode ser descrito de vrias maneiras, utilizando texto, figuras ou uma
combinao desses recursos.
Os pesquisadores de engenharia de software tm sugerido vrias maneiras de se fazer essa
descrio, geralmente organizada como modelos que contm as principais caractersticas do
processo (PFLEEGER, 2004). As PMLs podem ser formais, semi-formais ou informais
(CONRADI; JACCHERI, 1999).
Muitas PMLs foram desenvolvidas ao longo das ltimas dcadas, mas no h um
consenso sobre como os elementos do processo devem ser representados (ZAMLI; LEE,
2001). As PMLs so de fundamental importncia em uma ferramenta que apoie a modelagem
e execuo de processos, pois os desenvolvedores iro interagir com elas para definir e
compreender o processo. Mais detalhes sobre Linguagens de Modelagem de Processos sero
vistas mais adiante, na seo 3.2, utilizando como exemplo a Linguagem de Modelagem de
Processos do ambiente WebAPSEE.
2.1.3. Execuo de Processo de Software
Os PSEEs (Process-centered Software Engineering Environments) foram brevemente
introduzidos nos captulos 1 e 2. A seguir, uma viso geral de como um PSEE auxilia na
modelagem e execuo de processos de software.
De acordo com (CONRADI et al., 1994), os elementos do processo incluem atividades,
seus produtos e dependncias associadas, ferramentas de aplicao, papis desempenhados
por pessoas, usurios, organizaes, projetos e subprojetos. Esses elementos possuem vrias
naturezas e finalidades e interferem de diferentes formas medida que vo sendo inseridos no
processo. Outra caracterstica de processos de software que, segundo (CONRADI, R.;
27

FERNSTRM, C.; FUGGETTA, A., 1994), processos de software so orientados a pessoas
(human-oriented) e a interao entre pessoas e entre pessoas e ferramentas, que apoiam suas
atividades, so caracterizadas pela alta variabilidade e imprevisibilidade. Este fato aumenta
ainda mais a complexidade do processo de software resultante, e adiciona duras exigncias
gerncia do processo.
Um bom gerenciamento de projeto de software essencial para que os projetos sejam
desenvolvidos dentro do prazo e do oramento. O gerenciamento de software diferente de
outros gerenciamentos, pois o software algo intangvel, no h um processo de software
padro que garanta efetividade em todos os casos e grandes projetos de software so,
frequentemente, projetos nicos (SOMMERVILLE, 2003).
Para que o ambiente possa executar de maneira adequada um processo de software ele
precisa basicamente de um Mecanismo de Execuo de processos e de ser representado
atravs de uma PML.
O Mecanismo de Execuo de processos ou Mquina de Execuo de processos (Process
Engine) interpreta o modelo de processo instanciado de acordo com a semntica da linguagem
de modelagem (HUFF, 1996), gerenciando as informaes do ambiente e orientando os
desenvolvedores de acordo com esse modelo. Um dos objetivos principais desse mecanismo
manter o estado da execuo do processo consistente com o estado real da realizao das
tarefas. O mecanismo de execuo deve ser construdo com base na semntica da linguagem
de modelagem de processos adotada (LIMA REIS, 2003). A Figura 2.2 ilustra o
relacionamento do mecanismo de execuo com os outros componentes de um PSEE. O
termo instanciar significa transformar algo que um modelo (definido em alto nvel) em algo
executvel (especfico e tratvel por um mecanismo de execuo).
28

Figura 2.2 Interaes entre o mecanismo de execuo e outros componentes do PSEE.
Sendo o mecanismo de execuo o componente que interpreta um modelo descrito em
uma PML, pode-se dizer que a PML contribui com a flexibilidade de execuo atravs de
construtores adequados que facilitem o uso da mesma (LIMA REIS, 2003).
Segundo (LIMA REIS, 2003), o conceito de flexibilidade de execuo de processos de
software usado para definir a propriedade de mecanismos de execuo que toleram a
informalidade, o envolvimento humano e processos incompletos sem deixar que os processos
tornem-se inconsistentes. Requisitos de execuo de processos de software podem ser
encontrados em (LIMA REIS, 2003), oriundos de reviso da literatura sobre a execuo de
processos e divididos em trs categorias: requisitos de prescrio, requisitos de interao e
requisitos de flexibilidade.
Requisitos de Prescrio visam garantir que o modelo de processo seja executado pelo
mecanismo de execuo da forma como ele foi prescrito; Requisitos de Interao
estabelecem os requisitos da interao do mecanismo de execuo com seus usurios; e os
Requisitos de Flexibilidade, dada a importncia da flexibilidade na execuo de processos,
discutida anteriormente, lista os requisitos para se garantir flexibilidade na execuo de
processos. Qualquer ferramenta que tenha por objetivo realizar a execuo de processos de
desenvolvimento de software deve seguir estes requisitos, apresentados a seguir, na Tabela 1:

29

Tabela 1 Requisitos de execuo de processos. Adaptado de (LIMA REIS, 2003).
ID
Requisitos de Prescrio
Requisito Descrio
R1 Fluxo de controle
A sequncia de atividades no processo modelado deve ser obedecida
de acordo com o paradigma (tipo) de execuo adotado.
R2
Automao de
processo
Ativar automaticamente as atividades que podem ser executadas sem
interveno humana, atravs de uma integrao com as ferramentas do
ambiente.
R3
Gerncia de
objetos
O armazenamento persistente de todos os dados envolvidos no
processo.
R4
Registro da
histria do
processo
Coletar dados da evoluo do processo para permitir que o processo
melhore onde houver necessidade e seja corrigido para atender novos
requisitos.
R5 Coleta de mtricas
Prover mecanismos para coleta automtica de dados sobre o processo,
o produto e os participantes, assim como gerao de estimativas
quando possvel.
R6 Iterao
Algumas sequncias de atividades podem necessitar de repetio.
Deste modo, a ativao automtica de uma atividade a ser repetida
tarefa do mecanismo de execuo.
R7
Restries e
alocao de
recursos
Respeito s restries da execuo e gerncia da alocao de recursos
a fim de saber quem est trabalhando com o que e quais recursos so
necessrios para quais atividades.
ID
Requisitos de Interao
Requisito Descrio
R
8

I
n
t
e
r
a
o

c
o
m

g
e
r
e
n
t
e
s

R8.1
Permitir diferentes
vises de processo
Os gerentes devem poder monitorar o processo utilizando diferentes
perspectivas.
R8.2
Mostrar estado
atual e histrico do
processo
Permitir reversibilidade do estado atual e registro das decises (design
rationale).
R8.3
Modificao
dinmica do
processo durante a
execuo
Permitir que o gerente altere o modelo sendo executado de acordo com
algumas restries e que possa definir o modelo enquanto o processo
executa (processo incompleto).
R8.4
Independncia do
formalismo de
modelagem de
processos
Permitir que o gerente visualize o processo em formatos diferentes.
R8.5
Monitorao de
eventos e
tratamento de
excees
Informar ao gerente os eventos ocorridos e fornecer mecanismo para
trat-los automaticamente.
R
9

I
n
t
e
r
a
o

c
o
m

d
e
s
e
n
v
o
l
v
e
d
o
r
e
s

R9.1
Orientar
desenvolvedores
nas suas tarefas
Informar desenvolvedores sobre tarefas atribudas a eles, quais
documentos devem manipular e quais os resultados esperados.
30

R9.2
Fornecer
visualizao
adequada das
tarefas do processo
Definir como o desenvolvedor ir visualizar o processo. A
visualizao pode ser orientada a tarefas, orientada a documentos,
tarefas e documentos, metas ou orientada a ferramentas (SOUZA et
al., 2001).
R9.3
Obter feedback do
andamento do
processo
O feedback pode ser fornecido explicitamente pelo desenvolvedor
(formulrios, agendas) ou diretamente pelo PSEE (anlise de eventos
ocorridos).
R9.4
Fornecer
visualizao dos
estados do processo
(atual e anterior) e
mecanismo de
undo
Mesma visualizao definida para o gerente, mas restrita aos interesses
de desenvolvedores.
R9.5
Flexibilizar a
interao
Permitir que a orientao do processo possa ser adaptada durante
execuo. Esta interao geralmente determinada pela PML.
R
1
0

I
n
t
e
r
a
o

e
n
t
r
e

d
e
s
e
n
v
o
l
v
e
d
o
r
e
s

R10.1
Permitir
comunicao
informal
Atravs de mecanismos para comunicao sncrona e assncrona.
R10.2
Permitir gerncia
de reunies e
horrios
Fornecer mecanismos para discutir detalhes sobre a definio de
prazos e horrios de grupo.
R10.3
Permitir
monitorao de
produtos e
processos
Permitir que os desenvolvedores acompanhem o andamento do
processo, estando conscientes, por exemplo de quem manipulou
produtos.
R10.4
Controlar o acesso
aos objetos
Identificar usurios e seus papis e definir direitos de acesso aos
objetos
R10.5
Mltiplos nveis de
compartilhamento
de objetos
Permitir compartilhamento de objetos de qualquer tamanho e
granulosidade varivel.
R10.6
Registro do
histrico dos
objetos e
mecanismos de
undo e redo
Gerenciar verses dos objetos e permitir desfazer e refazer as ltimas
alteraes.
ID
Requisitos de Flexibilidade
Requisito Descrio
R11
Modificao
dinmica durante a
execuo
O ambiente deve permitir alterao do processo durante a execuo
mantendo a sua consistncia. A alterao pode atingir o fluxo de
controle (dependncias entre atividades), o contedo das atividades
(por exemplo, o script e datas que prescrevem o comportamento em
uma atividade), a alocao de desenvolvedores e recursos, dentre
outras.
R12
Execuo de
processos
incompletos
O processo deve iniciar sua execuo mesmo que alguns componentes
estejam faltando, como por exemplo, atividades, fluxos de controle e
detalhes de alocao.
31

R13
Instanciao do
processo durante
execuo
As informaes sobre pessoas e recursos para atividades podero ser
definidas durante a execuo. Esta caracterstica permite que seja
iniciada a execuo de um processo com partes abstratas, que sero
instanciadas somente quando estiverem aptas a executar. Dessa forma,
a alocao de pessoas e recursos pode ser adiada.
R14
Escolhas entre
caminhos
alternativos
No decorrer da execuo podem surgir decises previstas ou no em
tempo de modelagem. O mecanismo de execuo deve poder tomar
decises automaticamente com base em condies que consultam o
estado corrente do processo ou informaes do histrico do ambiente.
Essa tomada de deciso consiste em uma escolha de caminho
alternativo para continuao do processo.
R15
Adaptao ao
usurio
O mecanismo de execuo deve adaptar a sua interao de acordo com
o perfil do usurio. Isso evita que o ambiente torne-se muito intrusivo
para desenvolvedores experientes e permite que ele auxilie mais os
desenvolvedores novatos.
R16
Gerncia e
tratamento de
eventos
O mecanismo de execuo deve manter o registro de todos os eventos
ocorridos e ainda deve possibilitar a definio de estratgias para
tratamento desses eventos. Assim, possvel que o prprio mecanismo
de execuo seja capaz de modificar o processo durante a execuo em
resposta a algum evento. Alm disso, esse requisito livra o gerente da
tarefa de monitorar todas as ocorrncias do processo.

2.2. Atividades Peridicas
Alm das atividades estruturais de arcabouo que funcionam como alicerce para um
processo de software (seo 2.1), existem atividades de apoio ao processo de
desenvolvimento de software que acontecem vrias vezes durante o processo em intervalos de
tempo pr-determinados, as quais podemos denominar atividades peridicas. Como exemplo,
podemos considerar algumas atividades inerentes dos processos de apoio ao processo de
construo do software, tais como: gerao de releases do processo de Gerncia de
Configurao, coleta de mtricas referente ao processo de Medio, inspees/revises de
documentos do processo de Garantia da Qualidade, entre outros.
Ambientes que auxiliam o processo de software so de grande ajuda no acompanhamento
do projeto e apoio gerncia, trazendo benefcios tais quais os expostos no incio deste
captulo. Um mecanismo que apoie a utilizao de atividades peridicas em um ambiente de
desenvolvimento de software poder diminuir o esforo do gerente para definir e monitorar
essas atividades e atividades guarda-chuva no processo.
Muitos ambientes apoiam a utilizao de atividades repetidas e com execuo paralela,
mas no apoiam a utilizao de atividades peridicas (ver seo 4.10. Trabalhos Correlatos).
32

O apoio a atividades repetidas basicamente permitem que uma atividade ou conjunto de
tarefas sejam realizados mais de uma vez mediante uma condio de incio e/ou de parada em
um ponto especfico do processo; sendo assim, funcionam mais ou menos como um loop
condicional com escopo bem restrito em relao ao processo de software como um todo.
Porm, utilizar atividades repetidas no o mesmo que utilizar atividades peridicas.
Atividades peridicas so executadas sob a forma de perodos, que representam cada
repetio do conjunto de tarefas ou sub-processos dessa atividade. Esses perodos da atividade
peridica podem ser realizados vrias vezes em vrios pontos do processo. Sendo assim, as
atividades peridicas podem funcionar como atividades repetidas, mas podem atuar em um
escopo maior do processo e possuem um poder de abstrao e execuo de tarefas maior que
as atividades repetidas.

Para se gerenciar atividades peridicas atualmente, mesmo com o apoio das ferramentas
existentes, necessrio um grande esforo por parte do gerente de processos. necessrio
que este inicialmente identifique os pontos onde devem ser inseridas as atividades peridicas
e, de forma repetitiva, insira as atividades em cada ponto onde elas devem ocorrer. Onde
houver uma atividade peridica necessrio que o gerente tambm defina pessoas para
realizarem as tarefas, recursos a serem utilizados, artefatos a serem produzidos e consumidos,
dentre outros elementos relacionados ao processo que possam vir a interferir na execuo
desta atividade. Para cada ponto do processo onde a atividade peridica ocorra necessrio
que se defina novamente todos esses elementos.
Qualquer alterao que deva ser efetuada em todos os perodos de uma atividade peridica
necessita que o gerente percorra novamente o processo em busca dos pontos onde as
alteraes devem ser feitas, pois, da forma como so definidas, as ocorrncias da atividade
peridica ficam dispersas pelo processo. Afora o grande esforo para a definio dessas
atividades, monitor-las tambm no nada fcil, visto que deve-se procurar cada instncia da
atividade e ter uma idia geral delas, mesmo que elas estejam dispersas pelo processo.
Nas sees do captulo 4 as atividades peridicas sero apresentadas com mais detalhes,
inclusive com definies de termos utilizados no contexto de atividades peridicas neste
trabalho (seo 4.4).

33

2.3. Consideraes Finais do Captulo
A necessidade de se produzir software com qualidade motivou a criao de ambientes que
apoiassem o processo de desenvolvimento de software. Muitos modelos para a definio de
processo de software como o SPEM (OMG, 2008) surgiram para definir um padro de
modelagem, outros modelos tambm foram criados para a melhoria de processo de software,
como o CMMI (SEI, 2010) e o MPS-BR (SOFTEX, 2011).
Com o objetivo de se apoiar o processo de software, ferramentas de apoio ao processo de
desenvolvimento de software surgiram, dentre as quais destacam-se os PSEEs. Essas
ferramentas servem para apoiar o gerente e os desenvolvedores na execuo de suas tarefas. O
processo de desenvolvimento de software possui caractersticas peculiares que os distinguem
de outros processos, eles necessitam, portanto, seguir requisitos especficos para sua
modelagem e execuo, tais quais os apresentados em (LIMA REIS, 2003).
As atividades peridicas (PRESSMAN, 2010; 2011) so atividades importantes que
ocorrem de forma recorrente durante todo o processo de software, so atividades de apoio
focadas principalmente no gerenciamento, monitoramento e controle do projeto. Muitas das
ferramentas que apoiam o processo de software permitem que estas atividades sejam criadas
no processo, entretanto, como estas atividades ocorrem de forma recorrente por vrias vezes
em diferentes pontos sendo transversais ao processo, elas aparecem de forma geralmente
dispersa, no identificadas como peridicas e defini-las em vrios pontos um trabalho muito
dispendioso ao usurio gerente, que ainda deve monitorar esses grupos de atividades dispersas
no projeto. Devido a importncia dessas atividades em um projeto, necessita-se, portanto da
criao de algum mecanismo que apoie a modelagem e execuo das atividades peridicas no
processo.

34

3. O AMBIENTE WEBAPSEE
O WebAPSEE um ambiente de apoio ao desenvolvimento de software centrado em
processos, desenvolvido pelo Laboratrio de Engenharia de Software da Universidade federal
do Par (LABES-UFPA), desde 2003, a partir do trabalho de doutorado de (LIMA REIS,
2003) e atualmente est em sua verso 1.8. O ambiente foi construdo com uma arquitetura
distribuda e uso de web services para prover portabilidade entre diferentes plataformas e
linguagens e a comunicao com ouras ferramentas (COSTA, 2010). O WebAPSEE permite a
modelagem, execuo e acompanhamento de processos por meio de uma Linguagem de
Modelagem de Processos grfica, destacando-se o compromisso de flexibilizar a execuo de
processos, permitindo-se que o processo seja alterado em tempo de execuo (SALES, E.,
2009).
O WebAPSEE facilita a reutilizao de boas prticas gerenciais por diferentes projetos e a
coordenao de atividades de equipes dispersas geograficamente; considera aspectos
organizacionais; permite modificaes durante a execuo do processo, a interao entre seus
participantes e a gerao de relatrios de acompanhamento. Alm disso, o WebAPSEE apoia,
de forma integrada:
Gerncia de requisitos (SALES, M., 2008);
Reutilizao de processos (COSTA; SALES, E., 2007; COSTA, 2010);
Gerncia de configurao de artefatos (SILVA, A., 2008; SALES, E., 2009;);
Medio e estimativas (NASCIMENO, 2007);
Gerncia de conhecimento (OLIVEIRA, 2010);
Alocao de recursos humanos e definio de polticas de alocao de recursos
(SILVA, M., 2007).
35

O WebAPSEE possui trs aplicaes que interagem dinamicamente:
O cliente ManagerConsole, que possibilita a interao entre o gerente de software
e o ambiente;
O cliente TaskAgenda, que possibilita a interao entre o ambiente e o
desenvolvedor; e
O WebAPSEE Server, que atende as requisies feitas pelos clientes.
A seguir apresentada uma viso geral da arquitetura do ambiente.
3.1. Arquitetura Geral
A arquitetura do ambiente WebAPSEE dividida em trs camadas principais contendo
subcamadas, conforme a Figura 3.1:
1) Camada A (verde): representa a aplicao servidora do ambiente, que prov
servios de persistncia, verificao de consistncia para a modelagem, controle e
armazenamento de artefatos e execuo de modelos de processos de software
(WebAPSEE, 2006), contendo o Sistema Gerenciador de Banco de Dados e o
Repositrio de Controle de Verso.
2) Camada B (azul): camada cliente que basicamente oferece uma infraestrutura de
acesso aos servios da camada servidora (WebAPSEE, 2006), contm os
componentes encarregados da comunicao cliente-servidor.
3) Camada C (amarelo): camada de ferramentas clientes, que possui as ferramentas
que interagem diretamente a partir de interface grfica com o usurio, para entrada
de dados, modelagem de modelos de processos e visualizao de informaes
obtidas do servidor (WebASEE, 2006); onde esto os clientes da aplicao, como
formulrios, geradores de relatrio, o ManagerConsole e a TaskAgenda.
36

Figura 3.1 Viso arquitetural em camadas do ambiente WebAPSEE.
Dois dos principais componentes por meio dos quais os usurios interagem diretamente
com o ambiente so apresentados a seguir.
3.1.1. ManagerConsole
No WebAPSEE o gerente e os engenheiros de processo so responsveis pela modelagem
e instanciao do processo, ou seja, pela definio do fluxo das tarefas a serem realizadas,
assim de prazos, custos, estimativas e mtricas utilizadas, artefatos produzidos e consumidos e
pessoas e grupos envolvidos (FRANA, 2009).
O componente Manager Console do WebAPSEE, que pode ser visualizado na Figura 3.2,
o ponto de interao entre gerentes e o ambiente. Ele apresenta um editor de processos que
utiliza formulrios e uma PML grfica, a WebAPSEE-PML (Figura 3.4), baseada em redes de
atividades, utilizado pelo gerente de processos/projetos de software para modelagem,
execuo e acompanhamento dos processos de desenvolvimento da organizao, assim como
a representao de dados da organizao, tudo de forma visual.
O Manager Console permite aos engenheiros de processos modelar processos, gerenciar
execues de processos, visualizarem relatrios, cadastrar e gerenciar informaes
organizacionais, entre outros recursos fornecidos (COSTA, 2010).

37

Figura 3.2 Viso do gerente no WebAPSEE: componente Manager Console e sua PML
grfica.
3.1.2. TaskAgenda
A TaskAgenda (Figura 3.3) o ponto de interao entre os desenvolvedores e o ambiente
WebAPSEE. Atravs dela o desenvolvedor visualiza uma lista que relaciona tarefas a serem
realizadas, sendo permitido que cada desenvolvedor visualize apenas as tarefas pelas quais
responsvel. Alm da relao de tarefas a serem realizadas, a TaskAgenda permite que o
desenvolvedor visualize os artefatos a serem produzidos e os recursos a serem utilizados no
desempenho de cada tarefa. As atividades exibidas na TaskAgenda podem assumir os estados:
espera, pronta, ativa, pausada, e finalizada.
O desenvolvedor, por meio da TaskAgenda, fornece feedback sobre o andamento das suas
atividades e ainda permitido que ele faa upload de artefatos produzidos, requisitados em
algumas tarefas, e download de recursos disponveis que auxiliem a execuo das tarefas. O
feedback fornecido pelo desenvolvedor pela TaskAgenda imediatamente visualizado pelo
gerente no editor de processos do ManagerConsole (SALES, E., 2009).

38

Figura 3.3 TaskAgenda do WebAPSEE.
3.2. Linguagem de Modelagem de Processos
Representaes grficas so extremamente teis para ilustrar estruturas complexas de
forma direta e intuitiva (ERIGH; TAENTZER, 1999).
A modelagem de processos de desenvolvimento de software requer formalismos de alto
nvel para descrever aspectos de coordenao das atividades e relacionamento com a
organizao. Estes formalismos devem ser convenientes no somente para representao, mas
tambm para execuo. (WebAPSEE, 2006).
Para se modelar processos de desenvolvimento de software necessrio que se utilize uma
linguagem de modelagem de processos. A modelagem de processos no WebAPSEE utiliza
uma linguagem de modelagem (WebAPSEE-PML) que permite representao grfica de
processos criados a partir do meta-modelo apresentado em (LIMA REIS, 2003). baseada em
redes de atividades que podem ser decompostas. A notao grfica resumida utilizada pela

39

WebAPSEE-PML, que apresenta os smbolos visuais do alfabeto da PML mostrada na
Figura 3.4.

Figura 3.4 Notao da WebAPSEE-PML para modelagem de processos.
As atividades do processo so representadas por elipses identificadas com uma letra
representativa do tipo de atividade. Atividades Normais so as atividades executadas por
pessoas, as atividades Automticas so aquelas executadas automaticamente e as atividades
Decompostas so aquelas que abstraem sub-processos. Elementos organizacionais so
representados, pessoas, grupos, artefatos e recursos. As atividades podem ser ligadas por
conexes que definem o fluxo de atividades; conexes podem definir a sequencia entre duas
ou mais atividades, onde se possui uma origem e um destino, muitas origens e um destino
(conexes Join), uma origem e muitos destinos (conexes Branch). Alm destas, existem as
conexes de feedback, que representam loops entre atividades a partir de uma condio
associada. Com esse formalismo, um modelo de processo pode ser construdo pelo Gerente a
partir de smbolos grficos conectados (smbolos visveis ao usurio) e o detalhamento do
relacionamento com os outros componentes do modelo feito atravs de formulrios
especficos que apoiam essa tarefa.

40

Para a definio e especificao da PML do WebAPSEE, utilizou-se uma combinao de
mtodos de especificao formal, inspirada na abordagem GenGED (BARDOHL, 2000). O
grafo-tipo da APSEE-PML, que apresenta os elementos sintticos da linguagem,
apresentado na Figura 3.5.

Figura 3.5 Grafo-tipo da WebAPSEE-PML.
O grafo-tipo forma um diagrama que conecta vrios componentes da linguagem, sendo
que nem todos os smbolos do alfabeto possuem uma representao visual para o usurio da
linguagem (como os da figura 3.4). Este grafo chamado grafo-tipo, pois apresenta os
elementos da linguagem atravs de grafos tipados, ou seja, com atributos que podem definir
o estado de cada nodo. Uma explicao mais detalhada do grafo-tipo da WebAPSEE-PML
pode ser encontrado em (LIMA REIS, 2003) e mais detalhes sobre o formalismo de gramtica
de grafos adotado na especificao do WebAPSEE sero apresentados adiante, na seo 3.3.1.
Alm do grafo-tipo, para complementar a sintaxe visual, foram construdas regras de
gramticas de grafos compatveis com o grafo-tipo, que so utilizadas na definio e execuo
de processos no WebAPSEE. O conjunto dessas regras define o comportamento do ambiente.
Exemplos dessas regras so mostrados mais adiante, na seo 3.3.2.

41

3.3. Mquina de Execuo
O mecanismo de execuo de processos do WebAPSEE leva em considerao os
requisitos de execuo de processos de software (de prescrio, de interao e de
flexibilidade) encontrados em (LIMA REIS, 2003) que enfatiza a importncia dada ao
desenvolvimento humano no processo, com o objetivo de aumentar a flexibilidade da
execuo e suportar processos criativos e incerteza; trabalha com transformaes em vrios
nveis, atendendo as solicitaes de vrios usurios ao mesmo tempo e continuamente
verificando o estado corrente do processo. Um dos principais objetivos deste mecanismo de
execuo manter a consistncia entre o estado de execuo do processo e o estado real da
realizao das tarefas (COSTA, 2010).
Segundo (LIMA REIS, 2003), o mecanismo de execuo de processos fortemente
influenciado pelo formalismo de modelagem adotado e tem sido dada maior importncia a
escolha de formalismos de modelagem de processos de alto nvel, com representao grfica
que facilitem a tarefa de modelagem provendo conceitos mais prximos do usurio, sem
forar o conhecimento sobre detalhes de execuo; ao mesmo tempo essas linguagens
necessitam gerar processos que possam ser executados, portanto, tambm necessitam incluir
detalhes de execuo em sua semntica. O WebAPSEE foi desenvolvido sob um formalismo
de modelagem de alto nvel, tendo sua semntica mapeada para um modelo formal. Para tanto
foi escolhida a proposta de um meta-modelo de processos orientado a rede de atividades.
Para dar semntica execuo de processos, a especificao formal ajudar na definio
do mapeamento entre formalismos de alto nvel, tais como baseados em grafos e mecanismos
de execuo de baixo nvel, tais como os baseados em regras (JOERIS; HERZOG, 1999)
apud (LIMA REIS, 2003). A semntica definir como um modelo de processos dever ser
interpretado em alto nvel de abstrao (LIMA REIS, 2003).
O objetivo principal dos mtodos formais eliminar os erros de design de software
(NISSANKE, 1999). De acordo com (LIMA REIS, 2003), especificao formal a aplicao
de matemtica na especificao dos requisitos de software. Seu objetivo superar a falta de
preciso e ambiguidade inerentes s especificaes informais. Apesar da importncia de se
definir formalmente aspectos crticos da execuo e processos, a maioria das PMLs no
fornecem sintaxe e semntica formais, baseando-se apenas em descries textuais, semi-
formais ou somente em linguagem de programao de baixo nvel (LIMA REIS, 2003).
42

3.3.1. Gramticas de Grafos
Gramticas de Grafos generalizam gramticas de Chomsky usando grafos ao invs de
strings (RIBEIRO, 2000) apud (LIMA REIS, 2003) e baseiam-se no processo de
transformao que um grafo pode sofrer em funo de um conjunto de regras previamente
definidas. Um sistema especificado em termos de estados, que so modelados por grafos, e
mudanas de estados, modeladas por regras ou derivaes. (LIMA REIS, 2003).
A aplicao de uma regra r a um grafo G chamada de passo de derivao e se d quando
h uma ocorrncia do lado esquerdo (L) da regra no grafo G e o lado direito (R) da regra
define o grafo resultante da aplicao dessa regra.
As regras da mquina de execuo do WebAPSEE baseiam-se no formalismo definido por
gramticas de grafos para definir o comportamento do sistema. Existem diferentes abordagens
para gramticas de grafos, a abordagem utilizada na especificao do ambiente WebAPSEE
foi a abordagem algbrica atravs de mecanismos de tipagem nos grafos (LIMA REIS,
2003). Foi definido um grafo-tipo representando os tipos de nodos e arcos do sistema (Figura
3.5) e todos os outros grafos iniciais e derivados das transformaes, ocorridas mediante
passos de derivao, devem ser compatveis com o grafo-tipo.
A seguir ser apresentada uma introduo s regras da mquina de execuo do
WebAPSEE.
3.3.2. Regras da Mquina de Execuo
Para dar semntica execuo de processos de software no ambiente WebAPSEE foi
criado um conjunto de regras. A especificao das Regras da maquina de Execuo do
WebAPSEE utiliza o formalismo das Gramticas de Grafo. Estas regras definem as
transformaes que modificam o sistema e os estados do modelo. Como se trata de um
sistema interativo, as aes dos agentes e do gerente participam da semntica como geradores
de eventos que desencadeiam transformaes, Lima Reis (2003).
O grafo-tipo da WebAPSEE-PML (seo 3.2, Figura 3.5), foi aperfeioado para que
contivesse todos os smbolos necessrios s regras de transformao. O grafo-tipo completo
com os elementos sintticos da linguagem de modelagem e de execuo de processo do
WebAPSEE apresentado na Figura 3.6.

43

Figura 3.6 Grafo-tipo usado para semntica da execuo no WebAPSEE.

44

Alm da criao de regras a partir da transformao de grafos (passos de derivao), como
foi abordada na seo 3.3.1, em muitos casos so utilizadas condies negativas de aplicao
(NAC Negative Application Conditions) para descrever condies que devem ser negativas
para que a regra seja habilitada (LIMA REIS, 2003).
Na proposta inicial do ambiente APSEE, que posteriormente originou o ambiente
WebAPSEE, haviam aproximadamente 400 regras definidas para a mquina de execuo
proposta. Aps essa proposta inicial e mediante atualizaes, para acomodar novas
funcionalidades e se adaptar a outras modificaes no sistema, o conjunto de regras da
mquina de execuo do WebAPSEE atualmente, totaliza 506 regras de vrios tipos e 147
NACs associados, configurando-se um sistema de regras grande e complexo. Dentre as regras
existentes pode-se distinguir os seguintes macro grupos de regras:
Regras para Definio do Processos (Regras de Definio);
Regras para Execuo do Processos (Regras de Execuo);
Regras para Excluses;
Regras para Cpia.
Na Figura 3.7 tem-se um exemplo de regra da mquina de execuo existente atualmente
no WebAPSEE, que define a incluso de nova atividade em um processo. Nesta regra, dada a
requisio do usurio (NewNormalActivity(proces_id,new_id)) para a criao de uma
atividade normal vinculada a um Modelo de Processo de um Processo especfico, o lado
esquerdo (L) da regra mostra a existncia de um processo no concludo (P-st = not_started
ou enacting), que possui um modelo de processo, que por sua vez no contm uma atividade
com o identificador igual ao que se quer criar.

Figura 3.7 Regra para incluso de nova atividade em um processo.

45

O lado direito (R) da regra mostra que o processo e o modelo de processo foram mantidos
e a atividade foi criada com o tipo Activity_Normal, como solicitado, com o identificador
new_id; sendo tambm criadas ligaes com uma Agenda de agentes envolvidos e recursos
requeridos. Essa regra, portanto, define a semntica para insero de uma atividade Normal
em um dado Modelo de Processo de um Processo especfico e os estados do modelo
necessrios (antes) e resultantes (aps) para que a regra seja aplicada. As regras da proposta
inicial para o ambiente APSEE podem ser consultadas no trabalho de (LIMA REIS, 2003).
O ambiente WebAPSEE apresenta muitos diferenciais em relao a outros ambiente,
resultado de anos de desenvolvimento, incremento e melhorias realizadas no ambiente.
Atende vrios dos requisitos de execuo de processos (LIMA REIS, 2003) e sua interface
grfica e flexibilidade facilitam a modelagem de processos.
O grande nmero de regras definidas em sua mquina de execuo torna a manuteno
das mesmas complexa, entretanto fornecem grande capacidade para a modelagem e execuo
de processos.

46

4. PROPOSTA DE UM MECANISMO PARA A UTILIZAO
DE ATIVIDADES PERIDICAS NO AMBIENTE
WEBAPSEE
Como mencionado anteriormente, em sees do captulo 2, para se criar um mecanismo
que apoie a utilizao de atividades peridicas em um ambiente de desenvolvimento de
software necessrio atender inicialmente uma srie de requisitos de execuo do processo,
que compreendem requisitos de prescrio do processo, interao do mecanismo com
gerentes e desenvolvedores e de flexibilidade (seo 2.1.3). Alm dos requisitos para
execuo de processos, existem os requisitos especficos para atividades peridicas, que sero
apresentados adiante, na seo 4.4.3.
A automatizao do apoio utilizao de atividades peridicas pode permitir, dependendo
da capacidade fornecida pela ferramenta, que se realize a gerncia dessas tarefas ou sub-
processos, sob a forma de perodos, a partir de um nico ponto do processo. Facilitando,
assim, a definio, monitoramento, alteraes e consulta a perodos relacionados, o que, de
outra forma, seria muito dispendioso.
A seguir, ser apresentada uma viso geral (seo 4.1) de como as atividades peridicas
devem funcionar em um ambiente que apoie o processo de desenvolvimento de software. Em
seguida, algumas consideraes iniciais de decises e formalismos adotados na proposta
(seo 4.2). Depois, um exemplo da utilizao de atividades peridicas no mecanismo
proposto (seo 4.3) e a caracterizao das atividades peridicas por meio de definies de
terminologias adotadas neste trabalho, dos requisitos e casos de uso das atividades peridicas
(seo 4.4). Por fim, a extenso da WebAPSEE-PML (seo 4.5), a definio dos mecanismos
e regras de execuo para as atividades peridicas (sees 4.6 e 4.7). Ainda apresentado
como o usurio deve interagir com as atividades peridicas e uma seo de trabalhos
relacionados (sees 4.9 e 4.10, respectivamente).
47

4.1. Viso Geral
Um mecanismo que apoie a execuo de atividades peridicas basicamente deve permitir
de forma flexvel que a durao e os prazos para inicializao e para finalizao da atividade e
de seus perodos sejam definidos. Alm de permitir essa definio de forma flexvel, o
mecanismo deve estar integrado a uma mquina de execuo que acompanhe o processo
sendo realizado para que assim possa verificar constantemente o estado do processo e permitir
a execuo de cada perodo no tempo previsto e, ainda, permitir que o gerente do processo
possa decidir como solucionar problemas de atraso e outros contratempos no decorrer do
projeto.
Garantir que as atividades aconteam no tempo previsto significa permitir que elas
estejam disponveis para que seus responsveis possam execut-las no tempo previsto, pois, o
mecanismo em si no pretende executar de forma automtica tarefas do processo. Cada
atividade do processo que est sob responsabilidade de uma pessoa, depende exclusivamente
de seu responsvel, que fornece feedback do andamento da tarefa. Para monitorar a execuo
da atividade peridica o mecanismo deve monitorar a execuo de cada perodo e tarefa que o
compe, por meio do recebimento do feedback fornecido pelos desenvolvedores durante o
desempenho de suas tarefas.
Em um processo de software, permitir adaptaes e a melhoria da atividade em tempo de
execuo e, ainda, permitir a anlise do histrico de execuo dos perodos, so caractersticas
importantes que tambm devem ser implementadas pelo mecanismo de atividades peridicas,
pois permitem uma anlise do andamento do projeto e auxiliam na tomada de decises e
melhoria do processo. A utilizao de um elemento sinttico que represente e possa ser
utilizado pelo gerente para a modelagem e definio de atividades peridicas, como um cone
ou outro elemento grfico, tambm importante. Isso vai depender do apoio fornecido pelo
ambiente no qual esse mecanismo ser integrado, pois o ambiente deve dar suporte
modelagem grfica de processos, o que no pode ser garantido apenas pelo mecanismo para
execuo de atividades peridicas.
Adicionalmente, essas atividades devem ser flexveis o bastante para que se possa, por
exemplo, permitir concorrncia de perodos e que esses perodos possam ser executados e
configurados de forma independente uns dos outros. E, sempre que necessrio, que os
perodos sejam passveis de alteraes antes e durante a execuo, sempre mantendo a
consistncia do processo. Ou seja, que o conjunto de tarefas da atividade peridica possa ser
48

executado paralelamente em diferentes pontos e que cada perodo possa se adaptar s
necessidades especficas quela execuo por meio das configuraes feitas pelo gerente de
processo.
As atividades peridicas devem buscar atender requisitos para execuo de processos de
software, que podem ser encontrados em (LIMA REIS, 2003), divididos em trs categorias:
requisitos de prescrio, requisitos de interao e requisitos de flexibilidade, apresentados na
seo 2.1.3. Na seo 4.4.3 sero apresentados os requisitos para as atividades peridicas,
respeitando-se os requisitos de execuo de processos.
4.2. Consideraes Iniciais
O ambiente WebAPSEE permite a definio de atividades e a alocao de pessoas para
realizar as mesmas, tudo de forma grfica, entretanto no h o conceito de periodicidade, que,
por meio deste trabalho, deve ser inserido no sistema. Um apoio automatizado para atividades
peridicas integrado a um PSEE deve possibilitar a definio, instanciao, execuo,
acompanhamento e alteraes dessas atividades, atravs de interao com o usurio gerente, e
permitir que elas possam ser realizadas pelos usurios desenvolvedores de forma transparente.
A seguir, algumas consideraes a respeito do WebAPSEE e da insero de atividades
peridicas nesse ambiente:
Para se acomodar as atividades peridicas no ambiente WebAPSEE deve-se inserir
no sistema mecanismos que viabilizem a representao dessas atividades e
comportamento das mesmas;
Tendo-se os requisitos estabelecidos, deve-se inserir no grafo-tipo do WebAPSEE
um elemento sinttico para representar a atividade peridica no ambiente em
conformidade com os outros elementos sintticos definidos da linguagem de
modelagem de processos;
Visto que o ambiente WebAPSEE atualmente fornece mecanismos que permitem
grande flexibilidade, principalmente durante a execuo de processos, muitos
tratamentos e controles j existentes facilitam a acomodao das atividades
peridicas ao ambiente;
O mecanismo de execuo do WebAPSEE define uma ampla gama de tratamentos
para modelos de processo inclusive alteraes durante a execuo e reutilizao,
49

alm de um meta-modelo bem flexvel para a definio do processo, na
WebAPSEE-PML (ver sees do captulo 3), estreitamente relacionado ao
mecanismos de execuo;
Todos os aspectos comportamentais do sistema so estabelecidos por meio das
regras da mquina de execuo, tendo sintaxe baseada no grafo-tipo do meta-
modelo e criadas inicialmente pela proposta de (LIMA REIS, 2003),
posteriormente ampliadas durante as melhorias do sistema. O modelo permite que
novos comportamentos possam ser adicionados ao sistema por meio da criao de
novas regras ou alteraes de regras existentes;
Como a execuo de tarefas-folha pelos desenvolvedores, que fornecem feedback,
por meio da TaskAgenda (seo 3.1.2) j acontece de forma transparente, no ser
necessrio se preocupar a fundo com essa questo, pois ela j tratada
satisfatoriamente pelo sistema atualmente. O sistema trata o comportamento das
atividades que devero ser executadas e gerencia a comunicao destas aos
responsveis, mantendo tambm o estado do processo de acordo com o andamento
dessas tarefas.
Um diferencial deste trabalho, apoiado por todo esse aporte oferecido pela mquina de
execuo do WebAPSEE, ser permitir no s a modelagem, mas a execuo e o
acompanhamento das atividade peridicas. Como o ambiente WebAPSEE possui uma PML
grfica que facilita a modelagem, o acompanhamento e a comunicao do processo, inserir
uma representao grfica para a atividade peridica no processo igualmente facilitar a
modelagem, o acompanhamento e a comunicao das mesmas.
Quanto execuo destas atividades, o ambiente de execuo deve garantir, basicamente:
Controle automatizado da periodicidade da atividade, quando ela deve ser
realizada novamente no tempo e quem deve realiza-la, tratando de forma adequada
qualquer dependncia entre perodos;
Feedback da realizao da atividade ao Gerente para manuteno do estado de
cada perodo da atividade peridica (j garantido pelo WebAPSEE);
Flexibilidade na modelagem de processos, permitindo alteraes dinmicas, em
tempo de execuo;
50

Transparncia ao usurio desenvolvedor que ir realizar a atividade (garantido
pelo WebAPSEE);
Atualmente o ambiente fornece apoio para feedback, flexibilidade e transparncia, mas
apenas para atividades executadas uma nica vez: o Gerente recebe feedback das atividades
sendo executadas ou que j foram executadas de forma grfica por meio do componente
Manager Console; o Desenvolvedor recebe as tarefas que lhe so alocadas atravs do
componente TaskAgenda de forma transparente; e so permitidas alteraes dinmicas nas
atividades.
Resumidamente, o que deve ser feito a partir deste trabalho a insero do conceito de
periodicidade s atividades e garantir que isso ocorra adequadamente e de forma consistente
com as outras funcionalidades do ambiente WebAPSEE atravs da insero de elementos
sintticos na Linguagem de Modelagem de Processos e de modificao ou insero de regras
na Mquina de Execuo do WebASPEE. O que torna a complexidade dessa implementao
maior, inserir regras para a mquina de execuo do WebAPSEE que acomodem a
modelagem e execuo de atividades peridicas, perodos, prazos e marcos de forma
consistente com as regras j existentes na mquina de execuo. Como mencionado no
captulo 3, atualmente o WebAPSEE possui 506 regras de execuo formalmente definidas e
apesar de, para se implementar as atividades peridicas, no ser necessrio a alterao de
todas elas, ainda assim, esse nmero muito grande e precisam ser revisadas uma a uma e
analisado a necessidade de alteraes.
Apesar da representao grfica de cada etapa do processo ser importante e o WebAPSEE
permitir isso com muitos mecanismos que fornecem bastante flexibilidade modelagem e
execuo, no faz parte da proposta inserir graficamente as atividades peridicas no processo
assim que seja alcanado o prazo para que ela entre em execuo. O objetivo principal da
proposta fornecer um mecanismo para a modelagem e gerncia dessas atividades a partir de
um ponto nico e no de forma dispersa como feito atualmente, diminuindo o esforo do
gerente. O tratamento para essa insero grfica de perodos no ponto do processo em que
eles ocorrem relacionado como trabalho futuro.
4.2.1. Decises de Projeto
Como a definio de regras para a mquina de execuo um ponto chave para a efetiva
insero das atividades peridicas no WebAPSEE, definindo todo o seu comportamento, e a
51

quantidade de regras existentes no ambiente consideravelmente grande, principalmente
porque tratam vrios aspectos da modelagem e execuo de processos, tomou-se a deciso de
diminuir o escopo de interferncia nessas regras.
possvel distinguir grupos de regras de execuo dentre as regras existentes no ambiente
WebAPSEE. Inicialmente, para esta proposta, o foco ser nas regras que possibilitem
minimamente a definio e execuo de atividades peridicas e perodos em um modelo de
processo. A seguir, na Tabela 2, so apresentados os grupos de regras de execuo existentes
e quais as regras pertencem ao escopo do trabalho, as quais devem ser avaliadas para que
sejam criadas regras compatveis ou que regras pertencentes aos grupos sejam modificadas.
Tabela 2 Grupos de regras existentes no WebAPSEE e grupos que pertencem ao escopo.
Grupos
de
Regras
Tipos de Regras
Grupos
dentro do
escopo
Regras
para
Execuo
do
Processo
1 Regras que executam no incio da execuo do processo X
2 Regras que procuram atividades prontas para executar X
3 Regras que executam a partir da interao com usurio X
4 Regras que ajustam o estado de atividades fragmento X
5 Regras que propagam falhas entre atividades
6 Regras que propagam cancelamento entre atividades
7 Regras que tratam conexes Branch
8 Regras que tratam ativao (Firing) de conexes mltiplas
9 Regras que tratam Propagao de Feedback
10 Regras para instanciao de processos durante execuo X
11 Regras para manuteno do estado do modelo de processo X
12 Regras para manuteno do estado do recurso
Regras
para
Definio
do
Processo
1 Definio de Atividades X
2 Definindo conexes de artefato X
3 Definindo Conexes entre Atividades
4 Definio de Conexes Join
5 Definio de Conexes Branch
6 Definio de Cargos, Agentes e Grupos em Atividades
7 Definio de Recursos em Atividades
8 Teste de Fluxo de Controle entre atividades/conexes mltiplas
Regras
para
Excluses
1 Excluir atividades decompostas X
2 Excluir atividades automticas
3 Excluir atividades normais
4 Consistncias X
52

Grupos
de
Regras
Tipos de Regras
Grupos
dentro do
escopo
5 Excluir conexes
Regras
para
Cpias
1 Cpia de atividades
2 Cpia de Artefatos

Dentre os grupos que esto no escopo, existem regras referentes a: insero de atividades
peridicas e perodos no processo; vinculao de perodos a prazos temporais; conexo de
artefatos a atividades peridicas; excluso de atividades peridicas e de perodos; regras para
manter a consistncia entre os estados de perodos e das atividades peridicas; e regras para
manter a consistncia entre as regras para atividades peridicas criadas e as regras j
existentes no sistema;
Esto fora do escopo, por exemplo, as regras referentes a: insero de marcos e vinculao
de prazos a marcos; definio de conexes entre as atividades peridicas e outras atividades;
conexo de Agentes ou Grupos diretamente a atividades peridicas; conexo de recursos
diretamente a atividades peridicas; reutilizao de processos por perodos; e a cpia de
atividades peridicas.
4.2.2. Formalismos Utilizados
Os diferentes componentes envolvidos na definio do modelo no qual se baseia o
WebAPSEE foram especificados formalmente atravs de mtodo algbrico e da abordagem
de gramtica de grafos, constituindo uma base semntica de alto nvel de abstrao (LIMA
REIS, 2003). Essas abordagens foram descritas detalhadamente nas sees 3.2 e 3.3, portanto,
para mais detalhes sobre esses formalismos recomenda-se consultar essas sees.
A especificao formal das operaes mais importantes do WebAPSEE descrita por
Lima Reis (2003) como um conjunto de regras que definem o comportamento do sistema.
Qualquer modificao que exija um comportamento ou estado diferente do sistema (ou adio
de funcionalidades) exige que essas regras sejam reavaliadas e que sempre se mantenha a
consistncia do sistema e entre as regras.

53

4.3. Exemplo da Utilizao de Atividades Peridicas no Mecanismo
Proposto
Um exemplo de cenrio onde as atividades peridicas podem ser inseridas de forma a
facilitar o gerenciamento, monitoramento e controle do processo e, de acordo com o que foi
definido anteriormente, auxiliar na realizao das atividades guarda-chuva, pode ser mostrado
na implementao do processo de medio em um projeto de desenvolvimento de software.
Para mostrar esse exemplo, foi utilizado um projeto real de desenvolvimento, realizado
pelo Laboratrio de Engenharia de Software da Universidade Federal do Par (LABES-UFA),
onde foi utilizado o processo de medio, projeto este apresentado na Figura 4.1, e modelado
no ambiente WebAPSEE.

54

Figura 4.1 (1) Projeto que utiliza o processo de medio; (A), (B) e (C) Atividades
decompostas nas quais foi aplicado o processo de medio (contido em I, II e III).
Na Figura 4.1 o processo indicado por (1) o processo raiz do projeto onde vrias
atividades decompostas, que encapsulam sub-processos e demais elementos do processo, so
definidas. Neste cenrio, apesar da medio ter sido aplicada em vrios pontos, tomaremos
como exemplo apenas trs desses pontos do projeto onde medio foi aplicada: as atividades
decompostas (A), (B) e (C), tendo seus processos internos mostrados em (1.1), (1.2) e (1.3),
respectivamente.
55

Em cada uma dessas atividades o processo de medio foi aplicado em (I.), (II.) e (III). O
processo de medio padro aplicado formado pelas atividades: Coleta de Mtricas,
Elaborao de Indicadores, Reviso de Indicadores, Revisar Plano de Medio e Anlise,
Anlise Preliminar dos Indicadores e Apresentao e Anlise dos Indicadores.
Na Figura 4.2, observa-se o resultado final da execuo dos processos em cada ponto
analisado. Nos trs pontos, o processo padro foi utilizado, entretanto, devido situaes
ocorridas durante o processo que necessitaram mudanas, pode-se perceber que h pequenas
diferenas na modelagem do processo, especialmente em (II.), quando uma das atividades
passou a executar paralelamente ao fluxo principal.

56

Figura 4.2 Cada execuo do processo de medio nas atividades da Figura 4.1.
Embora algumas adaptaes locais tenham sido feitas, certamente o processo de medio
continuou buscando alcanar os mesmos objetivos, portanto, essas modificaes no
descaracterizaram o processo de medio, apenas foram adaptaes feitas ao longo do
processo quando foi preciso.
Na Figura 4.3 apresentado o mesmo cenrio, porm com a utilizao de uma atividade
peridica (D) para abstrair o processo de Medio a partir de um nico ponto. A atividade
peridica executa cada perodo do processo de medio (I.), (II.) e (III.) nos mesmos prazos

57

previstos configurados para acontecer anteriormente. Com a atividade peridica o gerente
passa a gerenciar os perodos a partir de um nico ponto, diminuindo seu esforo.
58

Figura 4.3 Utilizao da Atividade Peridica para implementar o processo de Medio.

59

Observa-se ainda que os perodos executados podem ser executados paralelamente (como em
II. e III.), dependendo de como forem configurados. Desta forma, as atividades peridicas
podem ser inseridas em vrios outros cenrios, como na gerncia de releases e baselines, na
manuteno do planejamento de gerncia do conhecimento, entre outros, apoiando de forma
flexvel a execuo de processos.
4.4. Caracterizao das Atividades Peridicas
Como mencionado anteriormente, as atividades peridicas so atividades executadas em
vrios momentos durante o processo de software de forma regular ou varivel e podem ser
associadas com as atividades definidas na literatura como guarda-chuva ou atividades de
apoio (PRESSMAN, 2006; 2011). Essas atividades, como qualquer outra, so definidas e
modeladas em um modelo de processo de software, com a ajuda de uma ferramenta de apoio,
pelo gerente de projeto/processo e ento executadas pelos desenvolvedores alocados para tais
atividades de acordo com a periodicidade das mesmas. Como so aplicveis vrias vezes
durante todo o processo, contribuindo, por exemplo, para a implementao de reas-chave do
processo de software como medio, reutilizao, controle do projeto, revises, gerncia de
configurao e gerncia de riscos (atividades guarda-chuva), as atividades peridicas so
importantes para o desenvolvimento do processo e alcance de resultados esperados.
Mais adiante, na seo 4.4.1, no intuito de esclarecer conceitos utilizados neste trabalho e
estabelecer um vocabulrio comum, sero apresentadas algumas definies a serem utilizadas
daqui em diante. Porm, antes de se definir e esclarecer estes conceitos, deve se deixar claro o
que so perodos, visto que perodos so a base da qual outros conceitos utilizados nesse
trabalho derivam.
Para que se prossiga com este conceito de perodo no contexto das atividades peridicas,
faz-se necessrio primeiramente afastar o leitor da ideia comumente atribuda a perodos pelo
censo comum. Segundo o dicionrio Aurlio (FERREIRA, 2009):
perodo. [Do gr. perodos, circuito, pelo lat. perodo.] S. m. 1. O
tempo transcorrido entre duas datas ou dois fatos mais ou menos
marcantes. 2. Qualquer intervalo de tempo, mais ou menos longo,
determinado ou indeterminado. 3. Perodo (2), marcado por certas
caractersticas gerais, e que se subdivide em pocas, fases, etc. 4.
poca, fase. 5. Estao, quadra; tempo, poca.
Adaptado de (FERREIRA, 2009).
60

No senso comum tm-se a ideia de que perodo algo que acontece de forma regular e
bem definida, sendo essa regularidade representada por meio de uma quantificao de tempo,
utilizada para caracterizar um conjunto de acontecimentos ou eventos. Utilizando-se desse
conceito, algumas ferramentas permitem a modelagem de processos com a criao de tarefas
peridicas, entretanto, essas atividades se aproximam mais de atividades repetidas com
durao e intervalos de tempo entre repeties regulares (ver seo 4.10. Trabalhos
Correlatos).
Uma forma mais didtica de se passar uma noo mais geral de perodos, e mostrar que o
termo pode ser utilizado de forma mais abrangente e flexvel, como est sendo apresentado no
contexto deste trabalho, fazendo-se uma analogia a outros campos de estudo que utilizam o
termo perodo de forma no regular. Em (FERREIRA, 2009), temos como exemplo de
perodos os perodos geolgicos, tidos como a diviso de cada uma das eras e que se
subdivide em pocas: cronologicamente, na era Mesozoica temos o perodo Trissico
(durao: aproximadamente 51,4 milhes de anos), o perodo Jurssico (durao:
aproximadamente 54,1 milhes de anos) e o perodo Cretceo (durao: aproximadamente 80
milhes de anos); segundo a geologia, essa era especialmente conhecida, por exemplo, pelo
aparecimento, domnio e desaparecimento dos dinossauros e a separao da Pangia em
Laursia, para o norte, e Gondwana, para o sul. Nesse exemplo pode-se perceber como os
perodos so agrupados por caractersticas comuns entre eles (aparecimento, domnio e
desaparecimento dos dinossauros e separao da Pangia) e a durao de cada perodo no
necessariamente regular (51,4 milhes de anos, 54,1 milhes de anos e 80 milhes de anos).
Portanto, o termo perodo de fato aplicado em vrios contextos diferentes (assim como
outros termos/definies), mas sempre objetivando definir algum acontecimento ou evento
com caractersticas gerais bem definidas que pode ser referenciado pelo intervalo de tempo
em que ocorreu, tendo este sido previsto ou no. Sendo assim, os perodos podem ser
agrupados de acordo com alguma caracterstica geral que seja comum entre eles.
Dois perodos podem ocorrer entre intervalos de tempo de mesma durao em dois
momentos diferentes do processo, logo, a durao do perodo pode ser utilizada como
caracterstica comum para definir um conjunto de perodos, mesmo que o intervalo de tempo
entre perodos seja varivel. Perodos podem ocorrer com durao varivel, mas
implementando um mesmo conjunto de tarefas para produzir um documento, logo, este
conjunto de perodos tm em comum a realizao de certas tarefas a fim de produzir um
documento.
61

Durante a execuo de um modelo de processo, o ideal que seja mantida a consistncia
entre o que acontece na realidade durante a execuo e sua representao (modelagem), logo,
a execuo e concluso de atividades depende da equipe de desenvolvimento que fornece
feedback das tarefas realizadas (pessoas realizando tarefas no mundo real). Como o processo
de desenvolvimento passvel de mudanas a qualquer momento, e elas ocorrem
frequentemente durante todo o processo, a definio de atividades e processos e, sobretudo,
seus perodos de execuo podem ser previstos e planejados de acordo com o calendrio do
projeto que deve ser seguido. Entretanto, a concluso real dessas tarefas depende do
desempenho de pessoas e de outros fatores relacionados ao projeto; sendo assim, no se pode
sempre determinar com exatido a durao de tarefas ou processos, garantir que eles
aconteam no tempo previsto ou supor que sempre ocorram em intervalos de durao iguais
(regulares). Desta forma, o tempo de durao, por exemplo, apenas uma caracterstica
cronolgica utilizada para definir um perodo, podendo ser previsto em um processo, porm,
mais facilmente determinado com exatido apenas aps seu incio e concluso.
A descrio ou caracterizao de um perodo pode ser feita com base em referenciais que
delimitam seu incio e fim (mais adiante veremos que podemos utilizar tanto referenciais
temporais quanto marcos para definir prazos de um perodo) e outras caractersticas gerais
com um objetivo nico que guia um grupo de perodos, formando uma atividade peridica.
4.4.1. Definies
Seguem algumas definies de termos definidos para serem utilizados no contexto deste
trabalho:
Perodo tempo decorrido entre dois eventos marcantes de incio e fim. Eventos esses
temporais ou baseados na mudana de estado de outras atividades (atividades-marco).
Cada perodo representa uma fase de realizao do conjunto de tarefas de uma atividade
peridica especfica, portanto, pode-se tambm dizer que perodo a realizao de uma
atividade peridica, ocorrida de forma previsvel entre dois eventos marcantes de incio e fim.
Um perodo caracterizado por tudo o que acontece durante o desempenho de um
conjunto de tarefas entre dois eventos definidos de incio e fim com um objetivo definido.
Perodos de uma mesma atividade peridica possuem os mesmos objetivos gerais. Cada
perodo deve ter sua prpria periodicidade definida e ser executado como um modelo de
processo independente de outros perodos, sendo tratado como uma unidade executvel ou
62

processo executvel, possuindo estado e configurao prprios. O estado da atividade
peridica depende dos estados individuais de cada perodo.
Por exemplo, se hoje iniciada a execuo da atividade peridica A est sendo
executado um perodo dessa atividade, quando esse perodo se encerrar e ento a atividade
peridica A for executada novamente, este j ser outro perodo em execuo dessa mesma
atividade peridica.
Atividade Peridica conjunto de tarefas ou processos realizados sob a forma de
perodos que possuem caractersticas gerais em comum. Cada fase de repetio da atividade
peridica equivale a um perodo.
Perodos de uma mesma atividade peridica podem ocorrer com durao regular ou
varivel, bem como os intervalos entre perodos. O que diferencia cada perodo realizado em
uma mesma atividade peridica, possibilitando referenci-lo de forma nica, so os eventos
os quais deram incio e encerraram sua realizao, delimitando sua durao e criando um
referencial temporal dessa realizao; ou seja, o momento em que eles ocorrem ou devem
ocorrer.
Atividades peridicas devem permitir que seus perodos possam ser previstos de acordo
como eles devem ocorrer, ou seja, permitir que sejam previstos conjuntos de perodos para
uma mesma atividade peridica com durao ou intervalo entre perodos regulares ou
variveis. Esta atividade pode ser uma atividade folha ou conter subatividades.
Considerando-se que as atividades guarda-chuva ocorrem durante todo o processo de
software, de forma recorrente em vrios pontos do processo, e que se pode pr-determinar
mais ou menos quando elas devem ser realizadas, seja com base em aspectos temporais (e.g.,
a partir de um dia especfico) ou em eventos (e.g., a partir do fim de uma atividade especfica)
ou combinaes destes, pode-se relacionar atividades peridicas a atividades guarda-chuva.
Prazo um tempo limite previsto para que uma atividade ou perodo comece, dure ou
termine. Pode ser indicado por um evento temporal ou por marcos.
Prazo de incio
3
: tempo limite previsto para que certa atividade ou perodo inicie
sua execuo. Na prtica, ser o tempo previsto em que um perodo ou atividade
estar autorizado a executar. Pode estar vinculado a evento temporal ou a marcos;

3
Tambm pode ser referenciado como prazo inicial ou prazo de inicializao.
63

Prazo de durao
4
: tempo limite previsto para que certa atividade ou perodo
execute (o tempo transcorrido entre o prazo de incio e o prazo de fim);
Prazo de fim
5
: tempo limite previsto para que certa atividade ou perodo finalize
sua execuo. Na prtica, ser o tempo previsto em que um perodo ou atividade
dever ser encerrado. Pode estar vinculado a evento temporal ou a marcos.
Todos os prazos anteriormente descritos so previses do que deve ocorrer e, portanto,
no garantem que a atividade seja iniciada, dure ou finalize exatamente como o previsto, mas
podem servir de parmetro para ajustes dessas previses em projetos futuros com objetivo de
que as tarefas sejam de fato realizadas de acordo com o previsto, entretanto servem como
parmetro para planejamento, acompanhamento e melhoria do processo em execuo ou
futuros projetos.
Marco um referencial pontual ou evento utilizado para indicar uma fase importante
durante o processo de software (OMG, 2008).
Prazos de incio e fim de perodos em atividades peridicas podem ser definidos a partir
de marcos no projeto. Esta definio de prazos baseados em marcos consiste na vinculao do
prazo de incio ou de fim mudana de estado de uma atividade-marco. Marcos so utilizados
para definir prazos iniciais e finais de atividades peridicas e seus perodos, vinculando-os a
estados de execuo de outras atividades. Por exemplo, pode se definir que um certo perodo
de uma atividade peridica X s poder iniciar quando a atividade Y iniciar sua
execuo.
Periodicidade configurao das caractersticas temporais dos perodos de uma atividade
peridica, da forma como estes devem acontecer e quando. Definio dos prazos de incio,
fim e durao.
A periodicidade de uma atividade peridica o conjunto de configuraes gerais de uma
atividade peridica, aplicveis a cada perodo, e de prazos previstos (individualmente) para
cada perodo que a compe.
A periodicidade de uma atividade peridica a forma como os perodos da atividade
foram configurados/definidos; mais especificamente, seus prazos e o que houver em comum
entre eles, se ocorrem, anualmente, semanalmente ou entre datas D e E.

4
Tambm pode ser referenciado simplesmente como durao prevista.
5
Tambm pode ser referenciado como prazo final ou prazo de finalizao.
64

Perodos regulares conjunto dos perodos de uma atividade peridica configurados
com periodicidades iguais.
Modo de definio de perodos para uma atividade peridica onde permitido serem
criados vrios perodos com mesma periodicidade (regulares), indicando-se a quantidade de
perodos, os prazos de incio e fim e o intervalo de tempo entre perodos; todos os perodos
possuiro a mesma definio, por exemplo, a cada 7 dias. Perodos regulares no podem
depender de marcos.
Perodos no-regulares ou variveis conjunto dos perodos de uma atividade peridica
configurados com periodicidades variveis.
Modo de definio de perodos para uma atividade peridica onde permitido serem
criados vrios perodos com periodicidades diferentes (no-regulares ou variveis), indicando-
se a quantidade de perodos, e configurando-os de forma independente. Perodos variveis,
definidos de forma detalhada, podem utilizar marcos para definir prazos de incio e fim.
4.4.2. Tipos de Atividades Peridicas
As atividades peridicas podem ser classificadas de acordo com a forma como elas
permitem a configurao de seus perodos. Basicamente, os perodos podem ser definidos por
meio de duas formas:
Atividades peridicas de perodos regulares (periodicidade regular): atividades
desse tipo permitem apenas perodos regulares. Estes so configurados
uniformemente a partir de um nico ponto de definio, ento a configurao
aplicada a todos os perodos e todos tero mesma periodicidade; e
Atividades peridicas de perodos variveis (periodicidade varivel): atividades
desse tipo permitem que cada perodo criado seja configurado individualmente.
Cada perodo criado ter sua prpria periodicidade.
Qualquer um dos tipos de atividades peridicas pode apresentar configuraes gerais,
neste caso, estas configuraes so aplicadas a todos os seus perodos, independentemente se
a atividade for composta de perodos regulares ou variveis. Essas configuraes gerais
podem ser, por exemplo, permitir que um perodo seja iniciado antes de seu prazo de incio
previsto, caso o perodo que o preceda j tenha finalizado.
65

4.4.3. Requisitos
De forma geral, inclusive para viabilizar a modelagem e execuo das atividades
peridicas, qualquer mecanismo de execuo deve procurar seguir os requisitos apresentados
em (LIMA REIS, 2003), oriundos de reviso da literatura sobre a execuo de processos (ver
seo 2.1.3). Estes requisitos visam garantir que o modelo de processo seja executvel com o
mnimo de alteraes na infraestrutura subjacente; ainda, estabelecem requisitos de interao
do mecanismo de execuo com seus usurios e de flexibilidade na execuo de processos.
Para definio do modelo proposto neste trabalho, considerando os requisitos para
execuo de processos presentes em (LIMA REIS, 2003) e algumas definies encontradas na
literatura, identificou-se como requisitos funcionais das atividades peridicas os itens
apresentados na Tabela 3. Esses requisitos foram gerados a partir de consultas a literatura,
reunies e entrevistas com especialistas, usurios e desenvolvedores do ambiente WebAPSEE
principalmente em decorrncia dos trabalhos de Iniciao Cientficas realizados pelo autor
desse trabalho, encontrados em (SANTOS et al., 2010; 2011), os quais foram comentados
anteriormente no captulo 1.
Tabela 3 Requisitos funcionais para atividades peridicas.
Requisitos Funcionais
ID Descrio
RF-01
O sistema deve permitir que uma atividade seja criada como sendo peridica ou que uma
atividade ou conjunto de atividades seja configurado como tal aps sua criao.
RF-02
O sistema deve permitir a definio de perodos regulares para uma atividade, onde a
periodicidade igual para todos os perodos de uma mesma atividade.
RF-03
O sistema deve permitir a definio de perodos no regulares, onde a periodicidade
destes pode ser diferente e configurada individualmente.
RF-04
O sistema deve permitir que o usurio configure a quantidade de perodos que uma
atividade peridica deve realizar e que esta possa ser consultada e alterada
posteriormente.
RF-05
O sistema deve permitir que a atividade peridica e seus perodos possam ser editados
durante sua execuo.
RF-06
O sistema deve permitir que as alteraes realizadas em perodos especficos possam ser
propagadas para os outros perodos ainda no iniciados.
RF-07
O sistema deve permitir que perodos incompletos sejam executados e partes abstratas
sejam instanciadas durante a execuo.
66

ID Descrio
RF-08
O sistema deve permitir que o histrico de execuo da atividade peridica e cada perodo
possa ser consultado.
RF-09
O sistema deve permitir que se possa optar por autorizar ou no que perodos da atividade
capazes de executar sejam adiantados caso um perodo em execuo seja finalizado antes
do prazo previsto.
RF-10
O sistema deve permitir que se possa optar por autorizar ou no que perodos, os quais
tenham o prazo de incio sido alcanado, e no houverem outras restries, executem
mesmo que o perodo que o anteceda cronologicamente no tenha sido concludo
(execuo concorrente).
RF-11
O sistema deve permitir que prazos de perodos possam ser definidos atravs de eventos
temporais ou atravs de marcos.
RF-12 O sistema deve permitir que possa existir mais de um marco associado a cada perodo.
RF-13
O sistema deve permitir que conexes sejam utilizadas entre atividades peridicas e outras
atividades.
RF-14
O sistema deve permitir que apenas um perodo de uma atividade peridica seja falhado
ou que uma atividade peridica seja falhada a partir do perodo em execuo.
RF-15
O sistema deve permitir que perodos no iniciados de uma atividade peridica sejam
cancelados ou que uma atividade peridica no iniciada seja cancelada.
RF-16
O sistema deve permitir que as atividades peridicas possam reutilizar modelos de
processos previamente definidos e armazenados.
RF-17
O sistema deve permitir que o usurio responsvel por executar um perodo seja
notificado de sua tarefa assim que o prazo de incio do perodo for alcanado e demais
dependncias forem satisfeitas e deve receber o feedback da realizao das tarefas.
RF-18 O sistema deve garantir que o controle de perodos no seja perdido e seja persistente.
RF-19
O sistema deve garantir que um perodo no possa ter seu prazo de incio com valor
menor que o prazo de finalizao do perodo ou atividade que o antecede; nem prazo de
finalizao maior que o prazo de incio do perodo ou atividade que o sucede.
RF-20
O sistema deve garantir, para que um marco seja associado ao prazo inicial de um
perodo, que a atividade-marco exista.
RF-21
O sistema deve garantir, para que um marco seja associado ao prazo final de um perodo,
que a atividade-marco exista e ocorra paralelamente ou posteriormente ao perodo.
RF-22
O sistema deve garantir que, quando chegar o tempo previsto para incio de um perodo,
se o perodo anterior estiver finalizado e no houverem outras restries, que a atividade
fique pronta para que o perodo seja executado e as tarefas disponveis aos responsveis.
67

ID Descrio
RF-23
O sistema deve garantir que, quando chegar o tempo previsto para incio de um perodo,
se o perodo anterior no estiver finalizado e no houverem outras restries (como a
oriunda do RF-09), que assim que este seja finalizado, a atividade fique pronta para que o
perodo seja executado e as tarefas disponveis aos responsveis.
RF-24
O sistema deve garantir que, quando conexes forem adicionadas a uma atividade
peridica, respeite-se e mantenha-se a consistncia da atividade, seus perodos e prazos
iniciais e finais, com as conexes.
RF-25
O sistema deve garantir que atividades no-peridicas que j tenham iniciado sua
execuo no possam se transformar em atividades peridicas.
RF-26
O sistema deve garantir o controle de vrios marcos diferentes associados a um mesmo
perodo e definidos pelo gerente, em unio com os prazos de incio e fim, para definir
quando o perodo deve estar disponvel execuo.

Vale ressaltar que, como as atividades peridicas so apenas um dos grupos de atividades
pertencentes ao processo de software e este trabalho objetiva inserir seu uso em uma
ferramenta que fornece apoio ao processo de software, muitos dos requisitos para execuo de
processos apresentados em (LIMA REIS, 2003) dependem do Mecanismo de Execuo e
Linguagem de Modelagem de Processos adotados pelas ferramentas. Portanto, no
responsabilidade direta das atividades peridicas aqui propostas atenderem todos os requisitos
de execuo de processos; na verdade, as atividades peridicas vo, na maioria das vezes,
utilizar as capacidades fornecidas pelas prprias ferramentas.
4.4.4. Casos de Uso
Nesta seo so especificados os casos de uso gerais e especficos definidos a partir dos
requisitos da seo anterior. Os casos de uso representam as funcionalidades que devem ser
fornecidas pelo sistema que viabilize a utilizao de atividades peridicas.
Na Figura 4.4 pode se observar os casos de uso gerais para atividades peridicas.
68

Figura 4.4 Casos de uso gerais para atividades peridicas.
O ator Gerente aquele responsvel por toda a modelagem e gerncia do processo de
software a ser seguido, ele quem define as atividades peridicas no processo. O ator
Desenvolvedor aquele que de fato executar cada perodo da atividade peridica e
fornecer feedback da execuo. Na Figura 4.5 apresentado o diagrama de casos de uso
especfico para atividades peridicas.

69

Figura 4.5 Casos de uso especficos para atividades peridicas.
Os casos de uso, apresentados nas Figuras 4.4 e 4.5, so descritos de forma textual nas
tabelas a seguir e posteriormente, ao final da seo, ser apresentada uma matriz de
relacionamento entre os casos de uso e os requisitos funcionais:

70

Tabela 4 Caso de Uso Geral 1. Gerenciar Atividade Peridica.
ID: UC 01
Caso de Uso
Geral:
Gerenciar Atividade Peridica
Descrio: Caso de uso relativo s funcionalidades aplicveis atividade peridica como um
todo, modelagem e definio destas. Este caso de uso viabiliza que uma atividade
peridica possa ser criada, excluda, cancelada, falhada e alterada em tempo de
execuo.
Requisito(s):
Relacionado(s)
RF-01, RF-05, RF-08, RF-13, RF-14, RF-15, RF-18, RF-19, RF-24 e RF-25.
Tabela 4.1 Caso de Uso 1.1. Criar Nova Atividade Peridica.
ID: UC 1.1.
Caso de Uso: Criar Nova Atividade Peridica
Descrio: Caso de uso relativo funcionalidade que permite criar uma atividade peridica e
adicion-la no processo.
Requisito(s):
Relacionado(s)
RF-01 e RF-18.
Tabela 4.2 Caso de Uso 1.2. Tornar Peridica uma Atividade No-Peridica.
ID: UC 1.2.
Caso de Uso: Tornar Peridica uma Atividade No-Peridica
Descrio: Caso de uso relativo funcionalidade que permite transformar uma atividade no-
peridica em atividade peridica.
Requisito(s):
Relacionado(s)
RF-01, RF-18, RF-19, RF-24 e RF-25.
Tabela 4.3 Caso de Uso 1.3. Configurar Atividade Peridica.
ID: UC 1.3.
Caso de Uso: Configurar Atividade Peridica
Descrio: Caso de uso relativo funcionalidade que permite editar o nome de uma atividade
peridica, seu tipo, estimativas da atividade e o roteiro (objetivos) e conectar a
atividade peridica a outras atividades.
Requisito(s):
Relacionado(s)
RF-05, RF-13, RF-18, RF-19 e RF-24.

71

Tabela 4.4 Caso de Uso 1.4. Excluir Atividade Peridica.
ID: UC 1.4.
Caso de Uso: Excluir Atividade Peridica
Descrio: Caso de uso relativo funcionalidade que permite excluir uma atividade peridica.
Requisito(s):
Relacionado(s)
RF-05, RF-18 e RF-24.
Tabela 4.5 Caso de Uso 1.5. Cancelar Atividade Peridica.
ID: UC 1.5.
Caso de Uso: Cancelar Atividade Peridica
Descrio: Caso de uso relativo funcionalidade que permite Cancelar uma atividade
peridica que no tenha iniciado a execuo de nenhum de seus perodos.
Requisito(s):
Relacionado(s)
RF-05, RF-15, RF-18 e RF-24.
Tabela 4.6 Caso de Uso 1.6. Falhar Atividade Peridica.
ID: UC 1.6.
Caso de Uso: Falhar Atividade Peridica
Descrio: Caso de uso relativo funcionalidade que permite Falhar uma atividade peridica
que tenha algum de seus perodo em execuo.
Requisito(s):
Relacionado(s)
RF-05, RF-14, RF-18 e RF-24.
Tabela 4.7 Caso de Uso 1.7. Consultar Atividade Peridica.
ID: UC 1.7.
Caso de Uso: Consultar Atividade Peridica
Descrio: Caso de uso relativo funcionalidade que permite consultar Verses (execues
anteriores) de uma atividade peridica.
Requisito(s):
Relacionado(s)
RF-08.

72

Tabela 5 Caso de Uso Geral 2. Gerenciar Perodos.
ID: UC 02
Caso de Uso
Geral:
Gerenciar Perodos
Descrio: Caso de uso relativo a funcionalidades aplicadas aos perodos, individualmente ou
em grupo. Este caso de uso viabiliza a adio de perodos uma atividade
peridica, a remoo, falha ou cancelamento de perodos; a definio de perodos
regulares ou vaiveis; o reuso de modelos de processos previamente definidos e
armazenados; permisso para execuo concorrente de perodos, permisso para
que perodos sejam adiantados e outras configuraes de periodicidade e
dependncia entre perodos.
Requisito(s):
Relacionado(s)
RF-02, RF-03, RF-04, RF-05, RF-06, RF-08, RF-09, RF-10, RF-14, RF-15, RF-
16, RF-18, RF-19, RF-22, RF-23, RF-24 e RF-26.
Tabela 5.1 Caso de Uso 2.1. Adicionar Perodo.
ID: UC 2.1.
Caso de Uso: Adicionar Perodo
Descrio: Caso de uso relativo funcionalidade que permite adicionar um perodo a uma
atividade peridica, caso esta no tenha sido finalizada.
Requisito(s):
Relacionado(s)
RF-04, RF-05, RF-18, RF-19 e RF-24.
Tabela 5.2 Caso de Uso 2.2. Configurar Perodos.
ID: UC 2.2.
Caso de Uso: Configurar Perodos
Descrio: Caso de uso relativo funcionalidade que permite definir a periodicidade do
conjunto de perodos da atividade peridica, se regular ou varivel; a definio de
um roteiro especfico para cada perodo; a modelagem dos perodos inclusive
durante a execuo e que perodos incompletos sejam executados; permite que
alteraes realizadas em um perodo especfico possam ser propagadas para
perodos no iniciados e que outro perodo possa receber ou no essa propagao;
que perodos possam ser adiantados ou executados de forma concorrente e o reuso
de modelos de processo previamente definidos e armazenados.
Requisito(s):
Relacionado(s)
RF-02, RF-03, RF-05, RF-06, RF-07, RF-09, RF-10, RF-16, RF-18, RF-19, RF-
22, RF-23, RF-24 e RF-26.

73

Tabela 5.3 Caso de Uso 2.3. Remover Perodo.
ID: UC 2.3.
Caso de Uso: Remover Perodo
Descrio: Caso de uso relativo funcionalidade que permite remover um perodo da
atividade peridica.
Requisito(s):
Relacionado(s)
RF-04, RF-05, RF-18 e RF-24.
Tabela 5.4 Caso de Uso 2.4. Falhar Perodo.
ID: UC 2.4.
Caso de Uso: Falhar Perodo
Descrio: Caso de uso relativo funcionalidade que permite Falhar um perodo, caso este
tenha sido iniciado.
Requisito(s):
Relacionado(s)
RF-05, RF-14 e RF-18.
Tabela 5.5 Caso de Uso 2.5. Cancelar Perodo.
ID: UC 2.5.
Caso de Uso: Cancelar Perodo
Descrio: Caso de uso relativo funcionalidade que permite Cancelar um perodo, caso este
no tenha sido iniciado.
Requisito(s):
Relacionado(s)
RF-05, RF-15 e RF-18.
Tabela 5.6 Caso de Uso 2.6. Consultar Perodos.
ID: UC 2.6.
Caso de Uso: Consultar Perodos
Descrio: Caso de uso relativo funcionalidade que permite consultar os perodos de uma
atividade peridica em qualquer estado de execuo que eles estejam.
Requisito(s):
Relacionado(s)
RF-08.

74

Tabela 6 Caso de Uso Geral 3. Gerenciar Prazos.
ID: UC 03
Caso de Uso
Geral:
Gerenciar Prazos
Descrio: Caso de uso relativo funcionalidade de criao de prazos de incio e fim para
perodos, configurao dos prazos, alterao e remoo.
Requisito(s):
Relacionado(s)
RF-05, RF-08, RF-11, RF-12, RF-18, RF-19, RF-24 e RF-26.
Tabela 6.1 Caso de Uso 3.1. Criar Prazo.
ID: UC 3.1.
Caso de Uso: Criar Prazo
Descrio: Caso de uso relativo funcionalidade que permite criar prazos de incio e fim para
um perodo e relacion-los a uma data.
Requisito(s):
Relacionado(s)
RF-05, RF-11, RF-12, RF-18, RF-19, RF-24 e RF-26.
Tabela 6.2 Caso de Uso 3.2. Configurar Prazos.
ID: UC 3.2.
Caso de Uso: Configurar Prazos
Descrio: Caso de uso relativo funcionalidade que permite editar as datas de prazos
previamente definidos.
Requisito(s):
Relacionado(s)
RF-05, RF-11, RF-18, RF-19, RF-24 e RF-26.
Tabela 6.3 Caso de Uso 3.3. Remover Prazo.
ID: UC 3.3.
Caso de Uso: Remover Prazo
Descrio: Caso de uso relativo funcionalidade que permite remover prazos previamente
definidos.
Requisito(s):
Relacionado(s)
RF-05, RF-12 e RF-18.

75

Tabela 6.4 Caso de Uso 3.4. Consultar Prazos.
ID: UC 3.4.
Caso de Uso: Consultar Prazos
Descrio: Caso de uso relativo funcionalidade que permite consultar todos os prazos de
incio e fim relacionados a um perodo.
Requisito(s):
Relacionado(s)
RF-08.

Tabela 7 Caso de Uso Geral 4. Gerenciar Marcos.
ID: UC 04
Caso de Uso
Geral:
Gerenciar Marcos
Descrio: Caso de uso relativo funcionalidade que permite a vinculao de prazos a
marcos, a criao desses marcos, a alterao e remoo.
Requisito(s):
Relacionado(s)
RF-11, RF-12, RF-18, RF-19, RF-20, RF-21, RF-24 e RF-26.
Tabela 7.1 Caso de Uso 4.1. Criar Marco.
ID: UC 4.1.
Caso de Uso: Criar Marco
Descrio: Caso de uso relativo funcionalidade que permite criar um marco e associ-lo a
um prazo de incio ou de fim de um perodo.
Requisito(s):
Relacionado(s)
RF-05, RF-11, RF-12, RF-18, RF-19, RF-20, RF-21, RF-24 e RF-26.
Tabela 7.2 Caso de Uso 4.2. Configurar Marco.
ID: UC 4.2.
Caso de Uso: Configurar Marco
Descrio: Caso de uso relativo funcionalidade que permite editar marcos associados a
prazos, selecionando-se uma atividade-marco e o estado esperado da atividade-
marco.
Requisito(s):
Relacionado(s)
RF-05, RF-11, RF-12, RF-18, RF-19, RF-20, RF-21, RF-24 e RF-26.
76

Tabela 7.3 Caso de Uso 4.3. Remover Marco.
ID: UC 4.3.
Caso de Uso: Remover Marco
Descrio: Caso de uso relativo funcionalidade que permite remover um marco e
desassoci-lo de seu respectivo prazo.
Requisito(s):
Relacionado(s)
RF-05, RF-12, RF-18 e RF-26.
Tabela 7.4 Caso de Uso 4.4. Consultar Marcos.
ID: UC 4.4.
Caso de Uso: Consultar Marcos
Descrio: Caso de uso relativo funcionalidade que permite consultar todos os marcos
vinculados a prazos de incio e fim definidos para um perodo.
Requisito(s):
Relacionado(s)
RF-08.

Tabela 8 Caso de Uso Geral 5. Fornecer Feedback da Tarefa Realizada.
ID: UC 05
Caso de Uso: Fornecer Feedback da Tarefa Realizada
Descrio: Caso de uso relativo funcionalidade que viabiliza a comunicao ao
desenvolvedor das tarefas das quais ele responsvel de executar dentro de um
perodo e a coleta do feedback dessas execues, fornecidas pelos responsveis.
Requisito(s):
Relacionado(s)
RF-17 e RF-18.

A seguir, na Tabela 9, a matriz de relacionamento entre os casos de uso e os requisitos
funcionais:

77

Tabela 9 Matriz de relacionamento Casos de Uso x Requisitos Funcionais.
Casos de
Uso
RF
01
RF
02
RF
03
RF
04
RF
05
RF
06
RF
07
RF
08
RF
09
RF
10
RF
11
RF
12
RF
13
RF
14
RF
15
RF
16
RF
17
RF
18
RF
19
RF
20
RF
21
RF
22
RF
23
RF
24
RF
25
RF
26
UC 01 x x x x x x x x x x
UC 02 x x x x x x x x x x x x x x x x x x
UC 03 x x x x x x x x
UC 04 x x x x x x x x x x
UC 05 x x

78

4.5. Extenso da WebAPSEE-PML
Baseando-se nas gramticas de grafos, o ambiente WebAPSEE tem sua PML formalmente
definida em seu grafo-tipo que estabelece a sintaxe da linguagem utilizada no ambiente (seo
3.2, Figura 3.5). Para que as atividades peridicas possam ser utilizadas no ambiente
necessrio, inicialmente, que sejam inseridos novos smbolos no alfabeto da linguagem
WebAPSEE-PML, para estender a sintaxe da linguagem.
A insero de novos elementos no algo trivial, visto que, cada um dos elementos
presentes na WebAPSEE-PML est integrado de forma que cada smbolo, associado a um
nome e um conjunto de atributos, utilizado para representar e raciocinar sobre o estado do
processo (LIMA REIS, 2003), no podendo haver inconsistncias. As setas no diagrama
representam arcos do grafo, sendo que, setas pontilhadas representam relacionamentos e setas
slidas representam chamadas de mensagem; o relacionamento Is_a, por exemplo, representa
uma relao de herana, sendo assim, de acordo com o grafo-tipo, uma Atividade
Decomposta (Activity_Dec), uma Atividade Normal (Activity_Normal) e uma Atividade
Automtica (Automatic), so uma Atividade (Activity) e herdam de Atividade seus atributos.
A parte principal do grafo-tipo da WebAPSEE-PML, referente s atividades, destacada na
Figura 4.6.
79

Figura 4.6 Grafo-tipo do modelo sinttico da WebAPSEE-PML (trecho).
Portanto, tendo-se seus requisitos e necessidades de interao sido definidos anteriormente
e baseando-se neles, procurou-se inserir os principais elementos dos quais este trabalho trata:
atividades peridicas, perodos e marcos, de forma coerente WebAPSEE-PML. Os novos
elementos do grafo-tipo foram definidos como mostrado na Figura 4.7, podendo ser
comparado com a definio original do mesmo trecho na Figura 4.6.

80

Figura 4.7 Atividades peridicas e elementos relacionados inseridos no grafo-tipo do
modelo sinttico da WebAPSEE-PML (trecho).
Para seguir o padro adotado no modelo original, utilizou-se a lngua inglesa. No modelo
da Figura 4.7, uma atividade peridica (Periodic), uma (Is_a) atividade que tem (has) um
conjunto de perodos (Period). Cada perodo possui uma identificao prpria (Id), um estado
(Pr-st) e datas de incio previsto (BeginDue) e fim previsto (EndDue), que so associadas a
datas. Um perodo ainda definido (Defined_by) por um modelo de processo (Process
Model), que pode ter outras atividades. Os marcos (Milestone) possuem uma identificao
(Id) e um estado (M-st), eles so aplicados a um perodo (To) e referenciam uma Atividade
Normal (refers_to), da qual ele espera um estado (Req_A-st), para que ele possa ativar um
prazo de incio ou fim (Dep, que pode ser end-end, para prazo de fim, ou start-start, para
prazo de incio) do perodo.
Como comentado na seo 3.2, nem todos os smbolos do alfabeto so visuais, ou seja,
disponveis visualmente ao usurio. Com relao aos elementos inseridos na WebAPSEE-
PML, apenas o elemento que representa a atividade peridica visvel ao usurio e
manipulvel graficamente pelo editor grfico do ManagerConsole.

81

4.6. Execuo das Atividades Peridicas
Objetivando-se a execuo das atividades peridicas, aos elementos inseridos no grafo-
tipo, apresentados na Figura 4.7, foram adicionados alguns smbolos necessrios s regras de
transformao. Alm disso, como a execuo envolve transformaes encadeadas, foi
necessrio inserir alguns smbolos sinalizadores aos marcos, como os relacionados a outros
elementos do grafo-tipo de (LIMA REIS, 2003) (Figura 3.6), para identificar situaes
especficas do processo, porm, o funcionamento desses smbolos sinalizadores o mesmo de
um atributo de um vrtice. A Figura 4.8 apresenta a estrutura sinttica e adicionados os
smbolos que auxiliam na execuo, tanto para as atividades peridicas quanto os j existentes
para os outros elementos a partir do grafo-tipo original.

Figura 4.8 Atividades peridicas e elementos relacionados inseridos no grafo-tipo do
modelo sinttico da WebAPSEE-PML (trecho).
Ao elemento Milestone foram adicionados os smbolos True e False. O sinal True marca
que uma condio foi avaliada e verdadeira; o sinal False marca que uma condio foi
avaliada e falsa. Desta forma, quando o marco, receber a indicao do sinal True, indica que
ele foi alcanado; enquanto o sinal for False, ele permanece aguardando (M-st = waiting).
A partir da utilizao dos elementos da WebAPSEE-PML em conjunto com os elementos
de execuo, pode-se desenvolver as regras para dar semntica de execuo s atividades
peridicas.

82

O sistema tambm deve controlar adequadamente os estados possveis de uma atividade
peridica e de seus perodos (individualmente). Para a definio das transies de estados
possveis para atividades e perodos, buscou-se adequar as definies propostas com os
estados dos outros tipos de atividades do WebAPSEE, definidos em (LIMA REIS, 2003). Os
perodos de uma atividade peridica seguem as regras para transio de estados da Figura 4.9.

Figura 4.9 Transio de estados de perodos.
Observa-se no diagrama da Figura 4.9 que um perodo, a partir do momento que criado,
entra no estado de Requisitos (Requirements), onde ainda no h atividades definidas para
este perodo e ele se resume a uma descrio dos seus requisitos. Passa ento para o estado
Abstrato (Abstract) quando atividades so definidas de forma abstrata dentro de um perodo,
ou seja, sem que ainda estejam definidos agentes para sua realizao, mas apenas cargos ou
apenas o tipo de recursos, por exemplo, e o perodo no est pronto para ser realizado, mesmo
que o prazo para incio do mesmo tenha sido alcanado. Quando alguma atividade do perodo
instanciada ela passa para o estado Esperando (Waiting), quando se espera apenas que as
dependncias para incio do perodo sejam satisfeitas para que ele possa ser executado.
Quando todas as dependncias para incio do perodo esto satisfeitas, prazo de incio e
marcos foram alcanados, e h atividades instanciadas, o perodo passa ento ao estado Pronto
(Ready), quando as atividades instanciadas so disponibilizadas nas TaskAgendas dos
desenvolvedores aguardando que estes dem inicio. Quando alguma atividade do perodo
iniciada, ele passa ento para o estado Ativo (Active) representando que o perodo est em
execuo; durante a execuo do perodo, se todos os desenvolvedores (agentes) solicitarem
pela TaskAgenda que todas as atividades do perodo sejam pausadas, o perodo passa para o

83

estado Pausado (Paused), bastando que uma atividade volte a executar para ele retornar ao
estado Ativo. Por fim, quando todas as atividades de um perodo forem finalizadas pelos
desenvolvedores, o perodo entra no estado Concludo (Finished).
Tambm procurando manter a consistncia com os estados definidos dos outros tipos de
atividades e seguindo o mesmo padro do ambiente WebAPSEE, os estado de uma Atividade
Peridica, como so compostas de perodos, depende dos estados dos perodos que a compe
e so apresentados na Figura 4.10.

Figura 4.10 Transio de estados de atividades peridicas.
Quando uma atividade peridica criada, seu estado Requisitos (Requirements), pois
possue apenas uma descrio geral e no possui perodos definidos (quando uma atividade
peridica criada, um perodo criado automaticamente, porm, este se encontra tambm no
estado de Requisitos). Quando ao menos um perodo da atividade peridica definido, mas
no instanciado, o estado da atividade peridica passa para Abstrata (Abstract). Quando h

84

perodos instanciados, o estado passa a ser Instanciada (Instantiated). Caso algum perodo
inicie sua execuo, a atividade passa para o estado Executando (Enacting), onde permanece
at que todos os perodos sejam concludos, quando ela passa para o estado Concluda
(Finished), ou quando a atividade falhada, passando para o estado Falhada (Failed). O
estado Mista (Mixed) existe para distinguir as atividades peridicas que no satisfaam os
requisitos para estarem nos demais estados.
A Falha ou Cancelamento de uma atividade ou perodo ocorrem da seguinte forma:
um cancelamento s pode ser solicitado se a atividade ou perodo no tiver sido iniciado, j a
falha, pode ser solicitada durante a execuo. A Falha encerra a atividade ou perodos em
execuo e cria uma nova verso deste, que refeita. O mecanismo de execuo deve, em
caso de falha e ao criar uma nova verso, por padro, criar uma nova verso da atividade
peridica apenas com os perodos no estado Requisitos; e caso um perodo seja falhado deve-
se verificar a existncia de marcos associados ao perodo, caso exista, estes devero ser
removidos. Qualquer alterao no processo definido que tenha como objetivo manter a
consistncia do sistema deve solicitar autorizao do usurio para que ela seja realizada.
Uma questo muito importante para que os perodos sejam gerenciados de forma
automtica que o mecanismo gerencie os prazos e outras dependncias para incio do
mesmo no tempo previsto, permitindo que eles sejam executados. O mecanismo deve tambm
fornecer flexibilidade para a definio desses prazos e seguir os requisitos para atividades
peridicas definidos na seo 4.3.3. Na Figura 4.11 apresentado um diagrama de atividades
que define como o mecanismo deve gerenciar esses prazos e dependncias entre perodos
definidos pelo gerente.
85

Figura 4.11 Diagrama de como o sistema gerencia a execuo de perodos.
Inicialmente, para que o mecanismo gerencie os prazos definidos, necessrio que ele
saiba se o perodo possui atividades instanciadas, ou seja, que podem ser executadas, mas
esto esperando que o prazo de incio seja alcanado. Neste momento o estado do perodo
Esperando (Waiting). Se o mecanismo verificar que para um dado perodo existem atividades
instanciadas, ele ento verifica se o prazo foi alcanado. O prazo pode ser definido como uma
data ou relacionado a um marco. Se o prazo no foi alcanado, o mecanismo verifica se
permitido que perodos sejam adiantados (cumprindo um dos requisito apresentados na seo
4.4.3). Se no, ele retorna a verificar quando o prazo alcanado. Se sim, ele verifica se o
perodo precedente est executando. A partir da, caso o perodo precedente no esteja
executando no h nenhum impedimento para que o perodo possa ser executado,
disponibilizando-se as atividades instanciadas na TaskAgenda dos desenvolvedores

86

responsveis por elas, aguardando a execuo no estado Pronto (Ready). Caso o erodo
precedente ainda esteja executando verifica-se se permitida a execuo concorrente de
perodos, se sim, o mecanismo, da mesma forma permite que o perodo inicie,
disponibilizando as atividades instanciadas na TaskAgenda dos desenvolvedores. Caso no
seja permitida a execuo de perodos concorrentes, o mecanismo volta a verificar quando o
prazo de incio alcanado.
A partir do momento em que um perodo tem sua execuo permitida e suas atividades
so iniciadas pelos desenvolvedores, o mecanismo fica apenas recebendo feedback dos
desenvolvedores at que o perodo seja concludo, mediante o cancelamento, falha ou
finalizao das atividades.
4.7. Regras Para a Mquina de Execuo
Tendo em vista atender todas as definies feitas anteriormente, foi elaborado um
conjunto de regras para a mquina de execuo do WebAPSEE, com foco no escopo definido
na seo 4.2.1, para definir o comportamento das atividades peridicas no processo. Como foi
discutido anteriormente, a grande complexidade e quantidade das regras atuais do
WebAPSEE aumenta muito o esforo necessrio para que se tenha uma idia de todas elas e
principalmente, para que se mantenha a consistncia entre elas com a insero de novas
regras.
Para modelar as atividades peridicas no processo e para que elas sejam executadas
conforme foi estabelecido nos requisitos da seo 4.4.3, foram estabelecidos um conjunto de
regras. Um exemplo dessas regras criada neste trabalho para serem adicionadas maquina de
execuo do WebAPSEE e permitir a insero de uma atividade peridica no processo pode
ser observada na Figura 4.12.
87

Figura 4.12 Regra para incluso de nova atividade em um processo.
Na Figura 4.12, o sistema recebe uma solicitao de insero de uma atividade peridica
em um ponto especfico do modelo de processo, sendo passados como parmetros o
identificador do processo no qual se pretende adicionar a atividade e o identificador que deve
ser utilizado por esta atividade. Seguindo o formalismo utilizado, para que a solicitao tenha
efeito, um estado do processo esquerda deve ser reconhecido e a transformao ou passo de
derivao estabelece que o estado posterior aplicao da regra encontra-se direita. Para
que a atividade seja criada necessrio que no exista previamente associada ao Processo, de
identificador process_id, uma atividade peridica de identificador new_id. Respeitadas as
condies, uma atividade peridica de identificador new_id criada, tendo um perodo
associado que definido por um Modelo de Processo no estado Requisitos.
O conjunto de regras modeladas para as atividades peridicas pode ser consultado no
Apndice B. Apesar da proposta inicialmente criar um escopo mais reduzido para a criao de
regras, no foi possvel alcanar o objetivo de se definir todas as regras para a mquina de
execuo, pois, alm de sua complexidade, estas precisam de um tempo de maturao que
ocorre a partir de muitos processos iterativos de definio, reviso, checagem de consistncia
e alteraes para que estejam integradas umas com as outras de forma a no haver
inconsistncias. Portanto uma extenso dessas regras e maior maturao so relacionados
como trabalhos futuros.

88

4.8. Modelo de Dados
Para se desenvolver o conjunto de classes integradas ao ambiente WebAPSEE, que
fornece muitos dados que podem ser utilizados pelas atividades peridicas, necessrio que
se alcance certa maturidade das regras da mquina de execuo. O processo de
implementao de qualquer funcionalidade que insira um novo mecanismo ainda no previsto
no meta-modelo do ambiente WebAPSEE requer que primeiramente se insira adequadamente
os elementos especficos no grafo-tipo que viabilizar posteriormente a criao do conjunto
de regras para a mquina de execuo. Ou seja, primeiramente, devem ser bem definidos e
especificados de forma consistente a sintaxe e o comportamento pretendidos. Em seguida,
mediante um comportamento que se mostre correto e consistente com o restante do sistema do
ambiente WebAPSEE, ser definido o modelo de dados a ser adotado e o que ser reutilizado
do ambiente.
Apesar de esboos do modelo de dados terem sido gerados e modificados com frequncia,
juntamente com os requisitos, no foi gerado um modelo de dados final. necessrio que se
feche inicialmente um conjunto de regras para a mquina de execuo.
4.9. Interao Com o Usurio
Os desenvolvedores no WebAPSEE utilizam-se do componente TaskAgenda, que
apresenta uma lista de atividades de responsabilidade de um desenvolvedor, a ser acessada
por cada desenvolvedor individualmente. Por meio da qual os desenvolvedores fornecem
feedback das atividades sendo realizadas. Por meio da TaskAgenda os desenvolvedores
continuaro interagindo com o WebAPSEE provendo esse feedback para a realizao de cada
tarefa e o estado de cada tarefa, imediatamente atualizado no modelo de processos e
visualizado no ManagerConsole.
O andamento das tarefas no depende inicialmente do estado do perodo ou da atividade
peridica, mas sim o contrrio. Os estados de cada atividade componente de um modelo de
processo definem o estado do modelo de processo, da mesma forma, os estados das atividades
(refletindo o feedback da execuo, fornecido pelos desenvolvedores) definem o estado de um
perodo e o estado dos perodos definem o estado da atividade peridica.

89

4.9.1. Manager Console
A interao com os usurios desenvolvedores, ocorrendo de forma transparente, continua
a mesma. Entretanto, focado na modelagem e controle das atividades peridicas por parte do
gerente, beneficirio direto dessa economia de esforos durante o processo de
desenvolvimento de software, o ManagerConsole necessitar implementar um novo modelo
de interao.
No ManagerConsole as atividades peridicas devem ser representadas por um novo cone
de atividade, o qual exposto na Figura 4.13. Seguindo o padro do ambiente WebAPSEE
para atividades, onde esta representada por uma elipse contendo no canto superior direito
uma letra P indicando a atividade peridica. De acordo com o estado da atividade, as cores
internas da elipse vo alterando, seguindo tambm o padro adotado pelo ambiente
WebAPSEE.

Figura 4.13 Representao da atividade peridica no ManagerConsole.
Atualmente, no ManageConsole, o usurio interage basicamente de duas maneiras com as
atividades, graficamente, no editor de modelagem, sem contar com os formulrios: Atividades
Decompostas so abstraes de sub-processos, ento, ao dar dois cliques em uma atividade
desse tipo o usurio levado a visualizar o contedo dela, um sub-processo; Atividades
Normais so atividades folha que podem ser executadas por uma pessoa ou grupo de pessoas,
dois cliques nessas atividades permitem apenas que se abra o formulrio de configurao
delas. As atividades peridicas se inseridas no ambiente WebAPSEE devem fornecer uma
forma de interao parecida com as Atividades Decompostas para visualizar o sub-processo,
mas, diferenciando-se porque ela pode possuir vrios perodos e em estados diferentes. Ento,
deve-se permitir que antes de se visualizar efetivamente a atividade peridica que se escolha
que perodo dessa atividade se deseja visualizar.
Outro mecanismo para configurao de atividades peridicas fundamentais e muito
utilizados no ManagerConsole do WebAPSEE para interagir com os usurios so os

Periodic
90

formulrios. O WebAPSEE j possui um conjunto de formulrios para configurao das
atividades. Entretanto, para as atividades peridicas foram construdos um conjunto de
prottipos de formulrios que levam em considerao elementos necessrios de forma geral
para outras atividades presentes nos formulrios existentes. Estes prottipos tambm so
baseados nos requisitos propostos e nos comportamentos previstos das atividades peridicas,
seus perodos e marcos, considerando o processo de edio. Eles surgiram inicialmente para
auxiliar o processo de elicitao de requisitos e foram sendo melhorados junto com os
requisitos, chegando a um estado estvel. A Figura 4.14 apresenta um desses prottipos,
referente configurao de atividades peridicas regulares.

91

Figura 4.14 Prottipo de formulrio para a configurao de atividades peridicas
regulares para o ManagerConsole.
Observa-se no formulrio da Figura 4.14, vrios requisitos de atividades peridicas
que ele busca atender. Ele dividido basicamente em quatro reas:
rea (1): Referente identificao da atividade, onde podem ser editados
nome e tipo da atividade e em (A) o tipo de periodicidade, que quando
alterado deve atualizar a rea (3);

92

rea (2): Referente s estimativas gerais da atividade peridica, onde os
incios planejado e realizado e fins planejado e realizado, correspondem ao
previsto ara a atividade toda. O incio planejado da atividade deve
corresponder ao incio planejado do primeiro perodo, o fim planejado da
atividade deve corresponder ao fim planejado do ltimo perodo;
rea (3): Referente reas de opes de periodicidade da atividade. Onde
podem ser configurados em (C), para as atividades peridicas regulares:
nmero de perodos, durao prevista de cada perodo e o intervalo previsto
entre perodos; e em (D), tanto para atividades peridicas regulares quanto
para variveis as opes:
o Permitir execuo concorrente de perodos, onde permitido que um
perodo possa ocorrer de forma concorrente com outros perodos da
atividade;
o Permitir propagao automtica da definio de perodos (propagador
default de perodos), onde pode ser habilitado ou no que exista um
nico perodo entre todos de uma atividade peridica que propague sua
configurao para os perodos ainda no iniciados que devam seguir
suas definies. Este perodo que funcionar como propagador pode
ser alterado; e
o Permitir que atividades sejam adiantadas, onde pode ser permitido ou
no que um perodo inicie caso seu prazo seja alcanado e um perodo
anterior ainda esteja executando. Caso esta opo esteja desmarcada,
se o prazo de incio de um perodo foi alcanado e o perodo anterior
ainda estiver executando, o perodo ter que esperar o perodo anterior
finalizar para poder iniciar.
rea (4): Referente configurao de perodos e roteiro ou objetivos gerais da
atividade peridica que devem ser seguidos pelos perodos. Este roteiro pode
ser editado em forma de texto quando a guia Roteiro for selecionada. Os
perodos so listados na guia Perodos, onde se apresentam em ordem
crescente de ocorrncia e seus estados individuais so indicados em (G) e
possuem smbolos indicadores ao lado esquerdo que indicam:
93

o ( ): marcador para o perodo propagador de configuraes
selecionado. Apenas um ou nenhum perodo pode estar marcado como
propagador de suas definies a perodos no iniciados;
o ( ): marcador que indica os perodos habilitados para receber a
propagao da definio de perodo feita pelo perodo marcado como
propagador. Perodos podem ter essa opo desativada, no recebendo
as definies propagadas;
Ainda, os perodos podem ser adicionados e visualizados e apresentam opes
de edio rpida disponveis ao usurio:
o I - ( ): ; permite editar os prazos de incio e fim do perodo;
o II ( ): permite editar o roteiro particular do perodo;
o III ( ): permite visualizar o perodo;
o IV ( ): permite abrir o formulrio de configurao de perodo;
o V ( ): permite excluir o perodo;
Para que os formulrios propostos para as atividades peridicas sejam utilizados no
ambiente WebAPSEE necessrio que sejam feitas modificaes ou adaptaes nos
formulrios atuais, sendo esta necessidade relacionada como trabalhos futuros. Os outros
formulrios propostos para as atividades peridicas, de criao de atividade, de configurao
da atividade, de configurao de perodo e de configurao de marcos, so apresentados no
Apndice A.
4.10. Trabalhos Correlatos
Um estudo rpido por ferramentas que apoiam processos, mostra que a maioria delas
limitada e no apoia a execuo de processos, geralmente auxiliando apenas a modelagem. De
forma geral, o apoio modelagem e execuo de atividades peridicas no encontrado nas
ferramentas, salvo raras excees. O meta-modelo SPEM (OMG, 2008), para definio de
processos, sistemas e seus componentes, no trata de forma especfica das atividades
peridicas. O SPEM verso 2.0 define atividade (Activity) como uma unidade geral de
trabalho que pode ser relacionada a produtos de trabalho e papeis de atores (performers), mas
tambm como sinnimo de processo, visto que uma atividade pode conter processos e outros
94

elementos de processo, permitindo ainda a definio geral de elementos do processo sem que
seja necessrio instanci-los imediatamente.
O meta-modelo SPEM 2.0 permite que uma atividade ou qualquer elemento que compe
uma atividade possa ser reutilizado por outra atividade ou processo dinamicamente,
permitindo-se herdar uma subestrutura completa ou parcial; instncias de atividades podem
herdar, mesclar algumas propriedade ou substituir todas as suas propriedades pelas
propriedades de outra atividade. Outro elemento do processo definido pelo meta-modelo a
Iterao (Iteration), que agrupa um conjunto de atividades que so repetidas mais de uma vez;
de forma geral, a definio do processo pode incluir informaes que indicam que as
definies do trabalho modelado devem ser repetidas vrias vezes em um projeto (modelagem
de iteraes) ou que devem haver mltiplas ocorrncias, uma atividade, por exemplo, pode ser
repetida. No prprio meta-modelo SPEM ressaltado o fato de que, este o conceito de
iterao utilizado no modelo, mas o conceito de iterao pode ser associado com diferentes
regras em diferentes mtodos. permitida, ainda, a execuo paralela e sequencial de
atividades e processos. Muitas das facilidades e flexibilidades fornecidas pela atual
arquitetura do meta-modelo poderiam ser utilizadas para definir atividades peridicas, mas
estas ainda no so previstas explicitamente.
Com relao a automao, no foram encontradas ferramentas que implementem as
atividades peridicas tal como esto sendo expostas neste trabalho. As ferramentas
pesquisadas, no implementam um facilitador especfico para estas atividades. Apenas uma
ferramenta encontrada diferencia essas atividades em especfico, dando-lhes um tratamento
especial, mas no atende a maioria dos requisitos para atividades peridicas apresentados na
seo 4.4.3 e apresentam flexibilidade limitada durante a definio e execuo dessas
atividades em modelos de processo. Muitas das ferramentas encontradas apoiam no mximo a
repetio de atividades e na maioria dos casos apenas a modelagem de processos e no a
execuo.
A maioria das ferramentas encontradas no apoia a definio e execuo de atividades
peridicas diretamente. As principais limitaes das ferramentas encontradas, com relao ao
apoio fornecido para facilitar a definio, execuo e acompanhamento de atividades
peridicas, foram:
Apoio modelagem de processos, mas no execuo;
Limitam-se realizao de atividades atmicas repetidas;
95

No permitem alterao de processos em tempo de execuo;
No consideram a previso de perodos irregulares;
No permitem consulta ao histrico de execuo de atividades executadas mais de
uma vez.
Essas ferramentas so direcionadas gerncia de processos de negcio (business process)
ou organizacionais, tratados por sistemas de workflow, e outras direcionam-se
especificamente para processos de desenvolvimento de software. A seguir, so apresentadas
algumas dessas ferramentas.
4.10.1. Microsoft Project Professional 2010
O ambiente Microsoft Project (MICROSOFT, 2010) uma ferramenta para modelagem e
gesto de processos que faz parte do conjunto de solues empresariais da Microsoft chamado
Enterprise Project Management (EPM). O Microsoft Project permite a modelagem e
acompanhamento de vrias fases de um projeto, cadastros, planejamento e coordenao de
equipes e do uso de recursos, e vrias formas de se visualizar e interagir com o processo
modelado. Dentro do ciclo de vida de um projeto o Microsoft Project adotado basicamente
durante as fazes de planejamento e controle do processo, pois no permite a execuo dos
processos modelados. Uma imagem da tela principal do ambiente retratada na Figura 4.15.
A verso da ferramenta utilizada para avaliao foi a Microsoft Office Professional 2010.
96

Figura 4.15 Tela principal do Microsoft Project Professional 2010.
Dentre os ambientes pesquisados, o Microsoft Project foi o nico que apresentou
diretamente a funcionalidade para definio de atividades peridicas, as quais so chamadas
tarefa peridica. Elas funcionam basicamente como uma lista de atividades folha
inicialmente previstas para serem realizadas de forma sequencial em intervalos regulares de
tempo entre as atividades e mesma durao previstas para cada atividade. permitido
reconfigurar cada sub-atividade (correspondendo ao que foi definido como perodos no
presente trabalho, entretanto no tratado nesses termos no Microsoft Project) individualmente
na tela principal do ambiente aps a criao da atividade peridica, porm, um controle geral
da atividade ou de conflitos durante a alterao da definio das sub-atividades,
principalmente de prazos muito trabalhoso, requisitando muitos passos que no so claros
ao usurio. Na definio das tarefas peridicas do Microsoft Project fornecida ao usurio
(Figura 4.16) percebe-se que elas so utilizadas como sinnimo de atividades repetidas:
inserir tarefa recorrente inserir uma tarefa que ocorra regularmente durante o projeto; por
exemplo, voc pode definir uma reunio de status semanal como uma tarefa recorrente.

97

Figura 4.16 Opo para insero de atividades peridicas no Microsoft Project
Professional 2010.
Na Figura 4.17, pode se observar as configuraes disponveis para as atividades
peridicas do Microsoft Project. Como informaes gerais principais da atividade tem-se a
durao total prevista da atividade, o intervalo de recorrncia e o padro de recorrncia.
Observa-se que um padro de recorrncia pode ser selecionado como diariamente, semanal,
mensalmente e anualmente, e a partir dessas opes so ativadas outras opes de
configurao dessas regularidades. Observa-se tambm que todas essas configuraes so
aplicadas de forma igual a todos os perodos que viro a ser realizados.

98

Figura 4.17 Configurao de atividades peridicas no Microsoft Project Professional
2010.

99

Como mencionado, apesar de implementar tratamento especfico para atividades
peridicas o Microsoft Project no considera muitos dos aspectos levantados pelos requisitos
para atividades peridicas apresentados na seo 4.4.3 e trata essas atividades como sinnimo
de atividades repetidas. No apresentam controle de consistncia com as configuraes gerais
da atividade peridica e no fornecido apoio execuo de processos. Uma configurao
mais detalhada de prazos de cada perodo (atividade), por exemplo, requer muito esforo por
parte do usurio. Apesar de prever inicialmente apenas a realizao de perodos regulares, a
ferramenta apresenta o diferencial, com relao ao tratamento de atividades peridicas nas
ferramentas analisadas, de fornecer um tratamento especfico para este grupo de atividades.
4.10.2. Oracle BPEL Process Manager
A Web Service Business Process Execution Language (WS-BPEL) (OASIS, 2007) prov
uma linguagem para a descrio formal de processos de negcio e protocolos de interao de
negcio. O BPEL um padro para construo de um conjunto de servios durante o fluxo
completo de processo, que oferece construes como estruturas de repetio, estruturas
condicionais, variveis e atribuies, permitindo que o processo de negcio seja definido
como um algoritmo. A verso WS-BPEL 2.0, de abril de 2007, define um modelo e uma
gramtica para descrever o comportamento de processos de negcio baseados em interaes
entre o processo e seus parceiros atravs de interfaces Web Services (OASIS, 2007).
A soluo Oracle BPEL Process Manager (ORACLE, 2009a) prov uma infraestrutura de
fcil utilizao e compreenso para criar, implantar e gerenciar processos de negcio baseados
na linguagem WS-BPEL e faz parte da Oracle SOA Suite (Service-Oriented Architecture
Suite) (ORACLE, 2009c). O Oracle JDeveloper (ORACLE, 2009b) um ambiente de
desenvolvimento que integra caractersticas de desenvolvimento para Java, SOA, Web 2.0,
Banco de Dados, XML e Web Services em uma nica ferramenta, por meio de uma interfaces
com o usurio com apoio a todo o ciclo de vida do desenvolvimento, apresenta
funcionalidades integradas para permitir a modelagem, codificao, debugging, testes, ajustes
e implantao de aplicaes e por padro com ele vem integrado o componente Oracle BPEL
Process Manager. A Figura 4.18 apresenta a modelagem de um processo de negcio com a
linguagem WS-BPEL utilizando o JDeveloper.
100

Figura 4.18 Tela do JDeveloper mostrando um processo modelado utilizando a linguagem
WS-BPEL.
Como mencionado anteriormente, o processo de modelagem na ferramenta, de acordo
com a linguagem WS-BPEL, funciona como a montagem de um algoritmo, atravs da adio
e composio de um conjunto de elementos sintticos. As primitivas definidas na gramtica
da linguagem sero interpretadas e executadas por um mecanismo de orquestrao. O Oracle
BPEL Process Manager capaz de executar os processos definidos sob o padro BPEL
armazenando seus estados em uma base de dados.
So exemplos de primitivas XML utilizadas numa composio de servio (FANTINATO,
201?): invoque (invoca um servio Web), receive (aguarda resposta de um ciente), reply (gera
resposta sncrona), assign (manipula dados), throw (indica faltas ou excees), terminate
(finaliza um processo), sequence (sequencia de atividades a serem invocadas), flow (usada
para definir um conjunto de atividades que podem ser invocadas em paralelo), if (seo),
while (repetio), pick (aguarda por um evento), wait (espera por certo tempo).
Portanto, no h um apoio direcionado especificamente para atividades peridicas
fornecido por essas ferramentas. Assim como outras ferramentas, esta tambm implementa
apenas repeties e atividades paralelas, mas no trata de muitos aspectos definidos nos
requisitos apresentados na seo 4.4.3. Talvez, devido essas ferramentas direcionadas a
definio de processos de negcio no considerarem atividades guarda-chuva, por exemplo,

101

como parte fundamental do processo de negcio, no seja preocupao delas implementar
facilidades para sua utilizao no processo. Entretanto, para que se implementem as
atividades peridicas com o apoio do Oracle BPEL Process Manager e outras ferramentas
baseadas na linguagem WS-BPEL, necessrio um grande esforo por parte do usurio,
principalmente para monitorar o uso das mesmas.
As ferramentas e respectivas verses consideradas nesta avaliao foram o Oracle
JDeveloper 11g, o Oracle BPEL Process Manager 11g e o Oracle SOA Suite 11g, disponveis
de forma gratuita pela Oracle a partir de um cadastro no website da empresa.
Foram definidas para as atividades peridicas, os requisitos necessrios para que elas
sejam implementadas e o comportamento que elas devem seguir, como o sistema deve
gerenciar essas atividades e seus componentes, como perodos, prazos e marcos. Um conjunto
de regras foi produzido, entretanto, este necessita adquirir maior maturidade. Formulrios
para facilitar a interao com o usurio tambm foram definidos, atendendo os requisitos das
atividades peridicas.
Dentre os trabalhos relacionados, as ferramentas mais encontradas so Sistemas de
Gerncia de Workflow (Workflow Management Systems WfMS), ferramentas que auxiliam
na modelagem e acompanhamento da execuo de processos de negcio (business process),
muitas delas baseadas na linguagem para modelagem de processos de negcio BPEL
(Business Process Execution Language). Ouras ferramentas, tanto PSEEs quanto ferramentas
de workflow, permitem que se modele repeties, porm, sempre por meio de muito esforo
por parte do usurio.
A maioria das ferramentas que apoiam a modelagem e/ou execuo de processos no
apoiam de forma direta a modelagem e execuo de atividades peridicas. As ferramentas de
forma geral apresentam limitaes considerveis principalmente para a execuo dessas
atividades, visto que no permitem a execuo de processos, funcionando apenas como
ferramentas de documentao do processo a ser seguido, mas no refletindo o estado real do
projeto.
Sendo assim, com base nas ferramentas pesquisadas, pde-se observar a necessidade de
um avano das ferramentas no sentido da utilizao de atividades peridicas. Como foi dito,
no incio da seo 4.10, as ferramentas existentes que apoiam o processo de desenvolvimento
102

de software ou processos de outra natureza apresentam diversas limitaes. De forma geral,
elas no apoiam a utilizao de atividades peridicas, sendo encontrada apenas uma
ferramenta que trata especificamente essas atividades.
Como avanos a partir da proposta desse trabalho em relao s outras ferramentas, pode-
se destacar, principalmente: a modelagem flexvel de atividades peridicas no processo de
software, permitindo alteraes dinmicas e a definio de perodos irregulares; o controle
centralizado dos perodos de execuo de uma atividade peridica, contribuindo para reduzir
o esforo repetitivo atualmente dispensado pelos gerentes para a modelagem dessas
atividades; a previso de execuo de atividades peridicas, formalmente definidas.
103

5. CONCLUSES
O presente trabalho procurou apresentar uma proposta de um mecanismo para a utilizao
de atividades peridicas no ambiente WebAPSEE. Apesar de todas as metas que se props
no terem sido alcanadas completamente, julgam-se vlidos todos os resultados aqui
apresentados.
5.1. Contribuies
Este trabalho contribuiu para o desenvolvimento do ambiente WebAPSEE, na medida em
que gerou muitos resultados que podem ser utilizados para a implementao das atividades
peridicas. Vrias das definies e discusses abordadas podem ser utilizadas por diferentes
ambientes e contriburam para se discutir uma abordagem para a execuo de atividades
previstas na literatura, mas que no est sendo tratada pelos ambientes que apoiam processos
de desenvolvimento software de forma adequada, aumentando muito o esforo do gerente
para sua definio e acompanhamento. A base de resultados parciais obtidas pode servir para
trabalhos futuros realizados no mesmo sentido.
5.2. Limitaes do Trabalho
O trabalho no conseguiu alcanar a maturidade das regras da mquina de execuo
propostas o que poderia possibilitar a implementao de fato de um prottipo, pelo menos
para a modelagem e execuo de perodos regulares. Assuntos especficos foram estudados,
como gramtica de grafos e toda a arquitetura do WebAPSEE, alguns resultados que no
chegaram em um formato final, como um modelo de dados inicial no foi reproduzido aqui,
pois, ainda no seria confivel sua utilizao. Mudanas de requisitos acontecendo de forma
104

frequente, como em vrios projetos de software, foram um dos motivos de no se ter chegado
ao resultado final esperado de alguns objetivos traados.
5.3. Trabalhos Futuros
Espera-se ainda continuar este trabalho procurando implementar de fato a utilizao de
atividades peridicas no ambiente WebAPSEE e estender os objetivos propostos inicialmente.
So relacionados como trabalhos futuros:
Como as constantes mudanas de requisitos ocasionaram muitos atrasos ao tempo
previsto para o desenvolvimento do trabalho, no foi possvel implementar as
atividades peridicas no ambiente WebAPSEE, entretanto, com a criao e
maturao de mais regras e utilizando os mecanismos aqui propostos, vivel a
implementao e utilizao dessas atividades no ambiente WebAPSEE;
Como o padro atual de formulrios do WebAPSEE que auxiliam na definio de
atividades no atendem todas as necessidades das atividades peridicas, para se
inserir esses formulrios so necessrias adaptaes de ambas as partes;
Como no foi uma proposta do trabalho a visualizao grfica dos perodos das
atividades peridicas em cada ponto do processo onde eles acontecem, pelos
motivos expostos no captulo 4, pode ser objetivo de um trabalho futuro verificar
essa possibilidade;
Pode ser implementado um mecanismo para visualizao de perodos que utilize
recursos grficos para se escolher o perodo da atividade a se visualizar e alterar
essa visualizao quando necessrio, isso poderia agilizar e facilitar ainda mais o
trabalho do gerente;
Devido a necessidade de maturao que no permitiu a concluso de muitas regras
criadas para a mquina de execuo do WebAPSEE referentes a atividades
peridicas, uma extenso dessas regras e maior maturao so relacionados aqui
como trabalhos futuros;

105

5.4. Consideraes Finais
Desde o incio o trabalho mostrou-se ambicioso, pois buscava a insero de uma nova
funcionalidade em um ambiente real de apoio ao processo de desenvolvimento de software,
funcionalidade esta pouco explorada na prtica por outros ambientes. O WebAPSEE um
ambiente muito grande e complexo, resultado de anos de desenvolvimento e melhorias,
porm, j apresenta muitas vantagens prontas que podem beneficiar os desenvolvedores do
sistema na melhoria do mesmo e os usurios em um processo real de desenvolvimento.
As atividades peridicas de forma geral no so tratadas por outras ferramentas da forma
como previstas nesse trabalho. Apenas uma soluo foi encontrada em outro trabalho neste
sentido, portanto, este trabalho, mais do que conclusivo, uma oportunidade para um trabalho
mais profundo no intuito de inserir as atividades peridicas como abordagem claramente
necessria em outros PSEEs.
O trabalho no pde abarcar todos os fatores relacionados com a implementao de
atividades peridicas no ambiente WebAPSEE. Entretanto, pretende-se dar continuidade ao
que se comeou aqui, provavelmente como tema de uma ps-graduao, procurar mais fatores
que podem ser tratados pelas atividades peridicas, melhorar o mecanismo proposto e
implementar de fato estas atividades no ambiente WebAPSEE.
106

REFERNCIAS BIBLIOGRFICAS
ABNT. NBR ISO/IEC 9126-1:2003: Engenharia de software Qualidade de produto, Parte
1: Modelo de qualidade. Rio de Janeiro: ABNT Associao Brasileira de Normas Tcnicas,
2003. 21 p.
ABNT. NBR ISO 10006:2000: Gesto da qualidade Diretrizes para a qualidade no
gerenciamento de Projetos. Rio de Janeiro: ABNT Associao Brasileira de Normas
Tcnicas, 2000. 18 p.
AMBRIOLA, V.; CONRADI, R.; FUGGETTA, A. Assessing Process-Centered Software
Engineering Environments. ACM Transactions on Software Engineering and
Methodology, TOSEM, New York, v. 6, n. 3, p. 283-328, July 1997.
ARBAOUI, S.; DERNIAME, J.; OQUENDO, F.; VERJUS, H. A Comparative Review of
Process-Centered Software Engineering Environments. Annals of Software Engineering,
The Netherlands, v. 14, p. 311-340, 2002.
BARDOHL, R. GenGED Visual Definition of Visual Languages based on Algebraic
Graph Transformation. Hamburg: Kovac Verlag, 2000.
BANDINELLI, S.; DI NITTO, E.; FUGGETTA, A. Policies and Mechanisms to Support
Process Evolution in PSEEs. In: INTERNATIONAL CONFERENCE ON THE SOFTWARE
PROCESS, ICSP, 3., 1994, Reston, USA. Proceedings... Washington: IEEE Computer
Society, 1994. p. 9-20.
BOEHM, B W. A View of 20th and 21st Century Software Engineering. In:
INTERNATIONAL CONFERENCE ON SOFTWARE ENGINEERING, ICSE06, 28.,
Shanghai, China, 2006, [S.l.]. Proceedings... New York: ACM Press, 2006. p. 12-29.
BOEHM, B. W. Software Engineering As It Is. In: INTERNATIONAL CONFERENCE
ON SOFTWARE ENGINEERING, ICSE, 1979, 4. Piscataway, NJ, USA. Proceedings...
[S.l.]: IEEE Computer Society Press, 1979. p. 11-21.
BOTTONI, P.; TAENTZER, G.; SCHR, A. Efficient Parsing of Visual Languages based on
Critical Pair Analysis and Contextual Layered Graph Transformation. In: 2000 IEEE
International Symposium on Visual Languages (VL'00), Seattle, Washington. Proceedings...
[S.l.]: IEEE Computer Society, 2000. p. 59.
107

CONRADI, R.; RAGASETH, M.; LARSEN, J.; NGUYN, M. N.; MUNCH, B. P.;
WESTBY, P. H.; ZHU, W.; JACCHERI, M. L.; LIU, C. EPOS: Object-Oriented Cooperative
Process Modelling. In: FINKELSTEIN, A. et al. (Ed.). Software Process Modeling and
Technology. Taunton: Research Studies Press, 1994. p. 33-70.
CONRADI, R.; FERNSTRM, C.; FUGGETTA, A. Concepts for Evolving Software
Processes. In: FINKELSTEIN, A. et al. (Ed.). Software Process Modeling and Technology.
Taunton: Research Studies Press, 1994. p. 9-31.
CONRADI, R.; JACCHERI, M. L. Process Modelling Languages. In: DERNIAME, J.;
KABA, B.; WASTEL, D. (Eds.) Software Process: Principles, Methodology, and
Technology. London: Springer-Verlag, 1999. p. 27-52. (Lecture Notes In Computer Science,
v. 1500).
CONRADI, R.; LIU, C. Revised PMLs and PSEEs for Industrial SPI. In: BOSCH, J.;
MITCHELL, S. (Eds.) Object-Oriented Technology, ECOOP97 Workshop Reader:
ECOOP97 Workshops, Jyvskyl, Finland, June 1997, Proceedings. London: Springer-
Verlag, 1998. p. 289-294. (Lecture Notes In Computer Science, v. 1357).
COSTA, A. J. S.; SALES, E. O. Uma Proposta para Reutilizao de Processos de
Software para o Ambiente WebAPSEE. 2007, 85 f. Trabalho de Concluso de Curso
(Graduao em Cincia da Computao) Curso de Bacharelado em Cincia da Computao.
Universidade Federal do Par, Belm, PA, fev. 2007.
COSTA, A. J. S. Um Mecanismo de Adaptao de Processos de Software. 2010, 103 f.
Dissertao (Mestrado em Cincia da Computao) Programa de Ps Graduao em Cincia
da Computao, Universidade Federal do Par, Belm, PA, 2010.
CUSUMANO, M.; MACCORMACK, A.; KEMERER, C. F.; CRANDALL, W. Software
Development Worldwide: The State of the Practice. In: IEEE Software, Volume 20, Issue 6,
November 2003. Journals... [S.l.]: IEEE Computer Society Press, 2003. p. 28-34.
EHRIG, H.; TAENTZER, G. Graphical Represenation and Graph Transformation. ACM
Computing Surveys (CSUR), New York, NY, Volume 31 Issue 3es, Sept. 1999.
ELLMER, E. Improving Software Processes. In: SOFTWARE ENGINEERING
ENVIRONMENT CONFERENCES, SSE95, 1995. Proceedings... Washington: IEEE
Computer Society, 1995. p. 74-83.
ENDRES, A.; ROMBACH, H. D. A Handbook of Software and Systems Engineering:
Empirical Observations, Laws and Theories. New York: Addison Wesley, 2003. 327 p.
(Fraunhofer IESE series on software engineering).
FANTINATO, M. Tutorial: Implementando um Processo de Negcio com BPEL. So Paulo:
USP, 201?. Disponvel em: <http://www.wsbpel.hd1.com.br/> Acesso em: 24 nov. 2011.
(trabalho vinculado ao projeto do programa Ensinar com Pesquisa da Universidade de So
Paulo, sob orientao do professor Doutor Marcelo Fantinato, do curso de Sistemas de
Informao).
FERREIRA, Aurlio Buarque de Holanda. Novo dicionrio Aurlio da lngua portuguesa.
4. ed. Curitiba: Ed. Positivo, 2009. 2120 p. ISBN 978-85-385-2825-8.
108

FERREIRA, Aurlio Buarque de Holanda. Miniaurlio: o minidicionrio da lngua
portuguesa. 6 ed. rev. e atualiz. Curitiba: Ed. Positivo, 2004.
FINKELSTEIN, A.; KRAMER, J. Software Engineering: A Roadmap. In: FINKELSTEIN,
A. The Future of Software Engineering, International Conference on Software Engineering,
ICSE00, 2000, p. 3-22. Proceedings... New York: ACM Press, 2000.
FRANA, B. B. N. Um Simulador Estocstico Baseado em Histrico de Processo. 2009,
121 f. Dissertao (Mestrado em Cincia da Computao) Programa de Ps Graduao em
Cincia da Computao, Universidade Federal do Par, Belm, PA, 2009.
FUGGETTA, A.; WOLF, A. (Ed.). Software Process. New York: John Wiley & Sons, 1996.
(Trends in Software, v.4).
FUGGETTA, A. Software Process: A Roadmap. In: INTERNATIONAL CONFERENCE ON
SOFTWARE ENGINEERING, ICSE, 22., 2000, Limerick, Ireland. Proceedings... New
York: ACM Press, 2000.
GARG, P.; JAZAYERI, M. Process-Centered Software Egineering Environments: A Grand
Tour. In: FUGGETTA, A.; WOLF, A. (Eds.) Software Process. New York: John Wiley &
Sons, 1996. p. 25-52. (Trends in Software, v.4).
GRAMBOW, G.; OBERHAUSER, R.; REICHERT, M. Towards Automatic Process-aware
Coordination in Collaborative Software Engineering. In: INTERNATIONAL CONFERENCE
ON SOFTWARE AND DATA TECHNOLOGIES, ICSOFT, 6th, 2011, Seville, Spain.
Proceedings... [S.l.: s.n.], 2011. p. 5-14.
HARRISON, W.; OSSHER, H.; TARR, P. Software Engineering Tools and Environments: A
Roadmap. In: INTERNAIONAL CONFERENCE ON SOFWARE ENGINEERING, ICSE,
22., 2000, Limerick, Ireland. Proceedings... New York: ACM Press, 2000. (Conferences on
the Future of Software Engineering, FOSE).
HEIDRICH, J. Chapter 5: Process Modeling Tools. University of Kaiserslautern, Fraunhofer,
Institute for Experimental Software Engineering (IESE), 2011. (Process Modeling Course
INF-31-51-V-7). Disponvel em:
<http://lectures.iese.fraunhofer.de/pm/downloads/pm2011chapter5modelingtools2slides.pdf>
Acesso em: 20 nov. 2011.
EHRIG, H.; TAENTZER, G. Graphical Represenation and Graph Transformation. ACM
Computing Surveys (CSUR), New York, NY, Volume 31 Issue 3es, Sept. 1999.
HUFF, K.E. Software Process Modelling. In: FUGGETTA, A.; WOLF, A. (Eds.) Software
Process. New York: John Wiley & Sons, 1996. p. 1-24. (Trends in Software, v.4).
JACCHERI, M.L.; BALDI, M.; DIVITINI, M. Evaluating the requirements for software
process modeling languages and systems. In: INTERNATIONAL WORKSHOP ON
PROCESS SUPPORT FOR DISTRIBUTED TEAM-BASED SOFTWARE
DEVELOPMENT, PDTSD, SCI/ISAS`99 Technical Session On Software Development
Methodologies, 1999, Orlando, Florida, USA. Proceedings... [S.l.], August 1999. p. 570-
578.
109

LIMA REIS, C. A. Uma Abordagem Flexvel para Execuo de Processos de Software
Evolutivos. 2003. 267 f. Tese (Doutorado) Programa de Ps-Graduao em Computao.
Universidade Federal do Rio Grande do Sul, Porto Alegre, RS, mar. 2003. Disponvel em:
<http://www.inf.ufrgs.br/prosoft/rsrc/Prosoft/PublicatedWork20050908191507/tese-
carla.pdf>. Acesso em: 3 nov. 2011.
LIMA, A; COSTA, A.; FRANA, B.; LIMA REIS, C. A.; REIS, R. Q. Gerncia Flexvel de
Processos de Software com o Ambiente WebAPSEE. In: Sesso de Ferramentas do Simpsio
Brasileiro de Engenharia de Software (SBES), 20, 2006. Anais... Florianpolis: Informtica-
UFSC, 2006.
LOPES, P. M. Apoio na Gerao de Plano do Projeto no Ambiente WebAPSEE. 2008.
103 f. Trabalho de Concluso de Curso (Graduao em Cincia da Computao) Curso de
Bacharelado em Cincia da Computao. Universidade Federal do Par, Belm, PA, dez.
2008.
MICROSOFT. Microsoft Project 2010 Product Information. Microsoft, 2010. Disponvel
em: <http://www.microsoft.com/project/en-us/product-information.aspx> Acesso em: 18 nov.
2010.
NASCIMENTO, L. M. A. Uma Abordagem Automatizada de Medio em Processos de
Software. 2007, 96 f. Dissertao (Mestrado em Cincia da Computao) Programa de Ps
Graduao em Cincia da Computao, Universidade Federal do Par, Belm, PA, 2007.
NISSANKE, N. Formal Specification: Techniques and Applications. London: Springer
Verlag, 1999.
OASIS. Web Service Business Process Execution Language (WS-BPEL), Version 2.0.
Organization for the Advancement of Structured Information Standards, 2007. Disponvel em:
<http://www.oasis-open.org/> Acesso em: 24 nov. 2011.
OLIVEIRA, J. F. Abordagem Para Implantao de Gerncia do Conhecimento Com
Apoio de Um Ambiente de Desenvolvimento de Software Centrado Em Processos. 2010,
156 f. Dissertao (Mestrado em Cincia da Computao) Programa de Ps Graduao em
Cincia da Computao, Universidade Federal do Par, Belm, PA, 2010.
OMG. Software & Systems Process Engineering Metamodel specification (SPEM),
Version 2.0. Object Management Group, 2008. Disponvel em:
<http://www.omg.org/spec/SPEM/2.0/> Acesso em: 20 nov. 2011.
ORACLE. Oracle BPEL Process Manager. Oracle, 2009. Disponvel em:
<http://www.oracle.com/technetwork/middleware/bpel/overview/index.html> Acesso em: 24
nov. 2011.
ORACLE. Oracle JDeveloper. Oracle, 2009. Disponvel em:
<http://www.oracle.com/technetwork/developer-tools/jdev/overview/index.html> Acesso em:
24 nov. 2011.
ORACLE. Oracle SOA Suite. Oracle, 2009. Disponvel em:
<http://www.oracle.com/technetwork/middleware/soasuite/overview/index.html> Acesso em:
24 nov. 2011.
110

OSELLUS. IRIS. Osellus, Toronto, Canad, 2009. Disponvel em: <http://www.osellus.com>
Acesso em: 20 nov. 2011.
PFLEEGER, S. L. Engenharia de software: teoria e prtica. 2. ed. So Paulo: Prentice Hall,
2004.
PRESSMAN, R. S. Software Engineering: A Practitioners Approach. 6th. ed. London:
McGraw-Hill, 2005.
PRESSMAN, R. S. Engenharia de software: uma abordagem profissional. 7. ed. Porto
Alegre: AMGH, 2011. 780 p. ISBN 978-85-63308-33-7.
REIS, R. Q.; LIMA REIS, C. A.; NUNES, D. J. APSEE-StaticPolicy: Verificao de polticas
estticas em modelos de processos de software. In: SIMPSIO BRASILEIRO DE
ENGENHARIA DE SOFTWARE, SBES, 15., 2001. Anais... Rio de Janeiro: SBC, 2001.
REIS, R. Q. APSEE-REUSE: Um Meta-modelo para apoiar a reutilizao de processos de
software. 2002. 215 f. Tese (Doutorado) Programa de Ps-Graduao em Computao.
Universidade Federal do Rio Grande do Sul, Porto Alegre, RS, jul. 2002. Disponvel em:
<http://www.labes.ufpa.br/quites/publicacoes/Tese_Rodrigo.zip>. Acesso em: 12 nov. 2011.
SALES, E. O. Gerncia de Configurao Integrada a Execuo de Processos de
Software. 2009, 129 f. Dissertao (Mestrado em Cincia da Computao) Programa de
Ps Graduao em Cincia da Computao, Universidade Federal do Par, Belm, PA, 2009.
SALES, M. F. Gerncia de requisitos integrada gerncia de projetos no ambiente
WebAPSEE. 2008, 130 f. Trabalho de Concluso de Curso (Graduao em Cincia da
Computao) Curso de Bacharelado em Cincia da Computao. Universidade Federal do
Par, Belm, PA, dez. 2008.
SANTOS, T. J. A.; REIS, R. Q. Construo e Avaliao de Ferramentas para o Suporte
ao Uso de Linguagens de Modelagem de Processos para Ambientes de Engenharia de
Software. Belm, Universidade Federal do Par (UFPA), Laboratrio de Engenharia de
Software da UFPA (LABES-UFPA), 2010. Relatrio Final de Bolsa de Iniciao Cientfica,
PIBIC/CNPq.
SANTOS, T. J. A.; REIS, R. Q. Extenso e Melhoria dos Recursos Disponveis na
Linguagem de Modelagem de Processos do Ambiente WebAPSEE. Belm, Universidade
Federal do Par (UFPA), Laboratrio de Engenharia de Software da UFPA (LABES-UFPA),
2011. Relatrio Final de Bolsa de Iniciao Cientfica, PIBIC/CNPq.
SEI. CMMI Capability Maturity Model Integration, Version 1.3. Pittsburg, PA,
Software Engineering Institute, Canegie Mellon University, 2010. Disponvel em:
<http://www.sei.cmu.edu>. Acessado em: 8 nov. 2011.
SILVA, A. R. S. Auditoria e Contabilidade de Gerncia de Configurao de Artefatos de
Software no Ambiente WebAPSEE. 2008, 89 f. Trabalho de Concluso de Curso
(Graduao em Cincia da Computao) Curso de Bacharelado em Cincia da Computao.
Universidade Federal do Par, Belm, PA, dez. 2008.
SILVA, M. A. WebAPSEE-Planner - auxlio alocao de pessoas em projetos de
software atravs de polticas. 2007, 139 f. Trabalho de Concluso de Curso (Graduao em
111

Cincia da Computao) Curso de Bacharelado em Cincia da Computao. Universidade
Federal do Par, Belm, PA, fev. 2007.
SNOWDON, R. A.; WARBOYS, B. C. An Introduction to Process-Centered Environments.
In: FINKELSTEIN, A. et al. (Ed.). Software Process Modeling and Technology. Taunton:
Research Studies Press, 1994. p. 1-8.
SOFTEX. MPS.BR Melhoria do Processo de Software Brasileiro, Guia Geral:2011.
[S.l.]: Associao para a Promoo da Excelncia do Software Brasileiro, 2011. 57 p.
Disponvel em: <http://www.softex.br/mpsbr/_guias/guias/MPS.BR_Guia_Geral_2011.pdf>.
Acessado em: 8 nov. 2011.
SOMMERVILLE, I. Engenharia de Software. 6. ed. So Paulo: Addison Wesley, 2003.
SOUSA, A. L. R.; LIMA REIS, C. A.; REIS, R. Q.; NUNES, D. J.; PIMENTA, M. S.
Analisando a Interao de Gerentes e Desenvolvedores em ambientes de processos de
software: classificao e exemplos. In: WORKSHOP CHILENO DE ENGENHARIA DE
SOFTWARE, 1., 2001, Punta Arenas, 2001. Proceedings... [S.l.: s. n.], 2001. Disponvel em:
<http://www.inf.ufrgs.br/prosoft/rsrc/Prosoft/PublicatedWork20050908202249/Chile01.pdf>.
Acessado em: 10 nov. 2011.
SOUSA, A. L. R.; LIMA REIS, C. A.; REIS, R. Q. Interao Humana Durante Execuo
de Processos de Software: Classificao e Exemplos Relatrio de Pesquisa RP-310.
Programa de Ps Graduao em Cincia da Computao, Universidade Federal do Rio
Grande do Sul, Porto Alegre, junho 2001. 67 p. Disponvel em:
<http://www.inf.ufrgs.br/prosoft/rsrc/Prosoft/PublicatedWork20050909135514/Interacao_Pro
cesso_Software.pdf >. Acessado em: 10 nov. 2011.
STANDISH GROUP INTERNATIONAL, The. CHAOS 2009 Summary Report, 2009.
TRAVASSOS, G. H.; KALINOWSKY, M. iMPS 2010: desempenho das empresas que
adotaram o modelo MPS de 2008 a 2010. Campinas, SP: SOFTEX, 2011. ISBN 978-85-
99334-20-1.
WebAPSEE. Documentao de Referncia do Sistema WebAPSEE 1.0 (beta). Belm:
Laboratrio de Engenharia de Software (LABES-UFPA), UFPA, 2006. Disponvel em:
<http://www3.ufpa.br/webapsee/>.
WebAPSEE. Manual de utilizao do ambiente WebAPSEE. Belm: LABORATRIO DE
Laboratrio de Engenharia de Software (LABES-UFPA), UFPA, 2008. Disponvel em:
<http://www3.ufpa.br/webapsee/>.
ZAMLI, K. Z.; ISA, N. A. M. A Survey and Analysis of Process Modeling Language.
Malaysian Journal of Computer Science, v. 17, n. 2, December 2004. p. 68-89.
ZAMLI, K. Z. Process Modeling Languages: A Literature Review. Malaysian Journal of
Computer Science, v. 14, n. 2, December 2001, p. 26-37. Disponvel em:
<http://mjcs.fsktm.um.edu.my/document.aspx?FileName=100.pdf>. Acessado em: 5 nov.
2011.
112

ZAMLI, K. Z.; LEE, P. Taxonomy of Process Modeling Languages. In: ACS/IEEE
International Conference on Computer Systems and Applications, AICCSA, 2001, Beirut,
Lebanon. Proceedings... [S.l.]: IEEE Computer Society 2001, p. 435-446.
ZELKOWITZ, M. V.; YEH, R. T.; HAMLET, R. G.; GANNON, J. D.; BASILI, V. R. The
Software Industry: A State of the Art Survey. In: BOEHM, B. W.; ROMBACH, H. D.;
ZELKOWITZ, M. V. (Eds.) Foundations of Empirical Software Engineering: the legacy of
Victor R. Basili. Berlin: Springer, 2005. p. 383-.
ZELKOWITZ, M. V.; YEH, R. T.; HAMLET, R. G.; GANNON, J. D.; BASILI, V. R. The
Software Industry: A State of the Art Survey. Technical Report TR-1290, May 1983.
Department of Computer Science, University of Maryland, College Park, MD 20742.
Disponvel em : <www.cs.umd.edu/~basili/publications/technical/T39.pdf> e
<http://drum.lib.umd.edu/bitstream/1903/7516/1/The%20Software%20Industry.pdf>. Acesso
em: 4 nov. 2011.
ZELKOWITZ, M. V.; YEH, R. T.; HAMLET, R. G.; GANNON, J. D.; BASILI, V. R.
Software Engineering Practices in the US and Japan. In: IEEE Computer, Volume 17, Issue 6,
IEEE. Journals... Los Alamitos, CA: IEEE Computer Society Press, June 1984. p. 57-66.
Disponvel em: <http://www.cs.umd.edu/~basili/publications/journals/J21.pdf>. Acessado
em: 13 nov. 2011.
ZELKOWITZ, M. V. Perspectives on Software Engineering, ACM Computing Surveys, v.
10, n. 2, p.197-216, jun. 1978. Disponvel em: <http://www.cs.umd.edu/~mvz/pub/zelkowitz-
cs-1978.pdf>. Acessado em: 4 nov. 2011.

113

APNDICE A Prottipos de Formulrios
Foram desenvolvidos os seguintes prottipo de formulrios para a criao e configurao
de atividades peridicas, perodos e marcos:

A.1. Prottipo de criao de atividades peridicas para o ManagerConsole.
.

114

A.2. Prottipo de formulrio para a configurao de atividades peridicas regulares para o
ManagerConsole, com a guia Roteiro ativada.

115

A.3. Prottipo de formulrio para a configurao de atividades peridicas regulares para o
ManagerConsole, com a guia Perodos ativada.

116

A.4. Prottipo de formulrio para a configurao de atividades peridicas variveis para o
ManagerConsole, com a guia Roteiro ativada.

117

A.5. Prottipo de formulrio para a configurao de atividades peridicas variveis para o
ManagerConsole, com a guia Perodos ativada.

118

A.6. Prottipo de formulrio para a configurao de atividades peridicas para o
ManagerConsole, com a guia Verses ativada.

119

ManagerConsole, com as guias Pessoas e Agentes Requeridos ativada.

120

ManagerConsole, com as guias Pessoas e Grupos Requeridos ativada.

121

ManagerConsole, com a guia Recursos ativada.

122

ManagerConsole, com a guia Artefatos ativada.

123

A.11. Prottipo de formulrio para a configurao de perodos de atividades peridicas
para o ManagerConsole, com a guia Roteiro ativada.

124

para o ManagerConsole, com a guia Prazo de Incio ativada.

125

para o ManagerConsole, com a guia Prazos de Incio ativada e prazos satisfeitos.

126

para o ManagerConsole, com a guia Prazo de Fim ativada e prazo sendo aguardado.

127

para o ManagerConsole, com a guia Prazos de Fim ativada e sem nenhum prazo definido.

128

A.16. Prottipo de formulrio para a configurao de marcos para perodos de atividades
peridicas para o ManagerConsole.

129

APNDICE B Regras Para A Mquina de Execuo
Alguns exemplos de regras desenvolvidas para apoiar a execuo de atividades peridicas
no ambiente WebAPSEE.

130

131

132

133

134

TCC 2011 CBCC-UFPA Thiago

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

TCC 2011 CBCC-UFPA Thiago

Uploaded by

Copyright:

Available Formats

UNIVERSIDADE FEDERAL DO PAR

INSTITUTO DE CINCIAS EXATAS E NATURAIS

, por terem me suportado e acompanhado de

You might also like