Já Alencar (1999), propõe diretrizes para o mapeamento dos mo<strong>de</strong>los organizacionais, queexplicitam os requisitos organizacionais, em componentes estruturais das linguagens <strong>de</strong>especificação precisas. Dessa forma, o objetivo é acrescentar às especificações precisas oscomponentes organizacionais que lhes faltem. Na proposta, a autora utiliza a técnica <strong>de</strong>mo<strong>de</strong>lagem i*, para levantar os aspectos organizacionais, e as linguagens Structured MAL(Structured Modal Action Logic) e OCL (Object Constraint Language) associada com UML,para a mo<strong>de</strong>lagem precisa.No trabalho <strong>de</strong> Teixeira (2009), é apresentado um conjunto <strong>de</strong> diretrizes que auxiliam oprocesso <strong>de</strong> construção <strong>de</strong> mo<strong>de</strong>los organizacionais i* para a fase <strong>de</strong> requisitos <strong>de</strong>talhados<strong>de</strong>rivando-os a partir <strong>de</strong> mo<strong>de</strong>los <strong>de</strong> ativida<strong>de</strong>s usando a Teoria da Ativida<strong>de</strong> (TA).Consi<strong>de</strong>ra-se como base a proposta apresentada em Cruz Neto (2008), direcionando o focopara a especificação dos requisitos do sistema computacional pretendido e seu impacto noambiente organizacional.No estudo <strong>de</strong> Estrada et al. (2001), é ressaltado a importância <strong>de</strong> incorporar informaçõessobre os processos <strong>de</strong> negócio na especificação <strong>de</strong> requisitos, on<strong>de</strong> o software é parte ativa<strong>de</strong>ste mo<strong>de</strong>lo <strong>de</strong> negócio. Estrada et al. (2001) apresentam uma abordagem para criação <strong>de</strong>mo<strong>de</strong>los <strong>de</strong> fluxos <strong>de</strong> trabalho (como ponto <strong>de</strong> partida para o <strong>de</strong>senvolvimento <strong>de</strong> mo<strong>de</strong>losorganizacionais i*) a partir <strong>de</strong> um mo<strong>de</strong>lo <strong>de</strong> requisitos, o qual permite <strong>de</strong>screver e modificarum processo <strong>de</strong> negócio sem consi<strong>de</strong>rar os <strong>de</strong>talhes da implementação. O autor cita que váriostrabalhos têm tentado utilizar técnicas <strong>de</strong> mo<strong>de</strong>lagem conceitual <strong>de</strong> sistemas <strong>de</strong> software, taiscomo a UML, para mo<strong>de</strong>lar processos <strong>de</strong> negócios, o que consi<strong>de</strong>ra uma abordagemineficiente, visto que essas técnicas não permitem especificar <strong>de</strong> forma clara relaçõesorganizacionais entre seus atores.No entanto, os trabalhos mencionados estão focados em <strong>de</strong>terminadas técnicas <strong>de</strong>mo<strong>de</strong>lagem organizacional, não se preocupando em realizar um estudo comparativo entre astécnicas existentes e, a partir <strong>de</strong>ssa análise, propor uma solução melhorada. Assim, acredita-seque a presente avaliação possa auxiliar nas ativida<strong>de</strong>s <strong>de</strong> elicitação, análise e documentação<strong>de</strong> requisitos, visto que engenheiros <strong>de</strong> requisitos po<strong>de</strong>rão compreen<strong>de</strong>r melhor o ambienteorganizacional e seus relacionamentos, bem como consi<strong>de</strong>rar os requisitos e objetivosorganizacionais previamente estabelecidos.Nota-se que a motivação para pesquisas na área <strong>de</strong> Engenharia <strong>de</strong> Requisitos tem crescidoconsi<strong>de</strong>ravelmente nos últimos anos. A causa disso é o fato <strong>de</strong> que a maioria dos problemas16
atribuídos a sistemas computacionais que não satisfazem clientes a<strong>de</strong>quadamente sãooriginados nas ativida<strong>de</strong>s realizadas nesta fase.2.2 Engenharia <strong>de</strong> Software ExperimentalA experimentação é uma disciplina muito importante para diversas áreas <strong>de</strong> pesquisa, queinclui a Engenharia <strong>de</strong> Software. Há uma compreensão cada vez maior na comunida<strong>de</strong> <strong>de</strong> ESque os estudos empíricos são necessários para avaliar, <strong>de</strong>senvolver ou melhorar processos,métodos e ferramentas para <strong>de</strong>senvolvimento <strong>de</strong> software e manutenção dos mesmos.Os experimentos são o centro do processo científico, pois somente os experimentos po<strong>de</strong>mvalidar as teorias ou explorar os fatores críticos para que as teorias possam ser formuladas ecorrigidas. Novos métodos, técnicas, linguagens e ferramentas não <strong>de</strong>veriam ser apresentadaspara venda sem experimentação e validação. É necessário que as novas invenções sejamavaliadas em comparação com as existentes. É importante ressaltar que experimentos nãoprovam nada, nenhum experimento oferece prova com certeza, eles apenas verificam aprevisão da teoria junto à realida<strong>de</strong> (Travassos, Gurov e Amaral, 2002).Segundo Travassos, Gurov e Amaral (2002), a Engenharia <strong>de</strong> Software possui aspectosexplícitos <strong>de</strong> produção, pois consi<strong>de</strong>ra o processo <strong>de</strong> criação do software. Por outro lado,características relacionadas à competição e ao time-to-market exigem a melhoria contínua daqualida<strong>de</strong> do processo e do produto, apresentando a parte científica da Engenharia <strong>de</strong>Software.Wohlin et al. (2000) afirmam que existem quatro métodos relevantes para a condução <strong>de</strong>experimentos na área da Engenharia <strong>de</strong> Software: o método científico, o método <strong>de</strong>engenharia, o método experimental e o método analítico.Travassos, Gurov e Amaral (2002) supõem que a abordagem mais aceita para aexperimentação na Engenharia <strong>de</strong> Software seja o método experimental, que consi<strong>de</strong>ra aproposição e avaliação do mo<strong>de</strong>lo com os estudos experimentais. O método experimental, queserá utilizado nesse trabalho, sugere o mo<strong>de</strong>lo, após <strong>de</strong>senvolve o método qualitativo e/ouquantitativo, aplica um experimento, me<strong>de</strong> e analisa, avalia o mo<strong>de</strong>lo e repete o processo.Dessa forma, essa abordagem é consi<strong>de</strong>rada orientada à melhoria revolucionária. Os autorescitam que os outros métodos po<strong>de</strong>m ser utilizados para a resolução <strong>de</strong> problemas naEngenharia <strong>de</strong> Software.17
- Page 2 and 3: FERNANDO LUIZ GRANDOAVALIANDO TÉCN
- Page 4 and 5: DEDICATÓRIAAos meus pais e minha i
- Page 6 and 7: AGRADECIMENTOSA Deus, pela saúde e
- Page 8 and 9: 3.24: Notações básicas para Caso
- Page 10 and 11: Lista de Abreviaturas e SiglasB2BBP
- Page 12 and 13: SumárioLista de Figuras ..........
- Page 14 and 15: ResumoHoje em dia, o desenvolviment
- Page 16 and 17: conjunto estruturado de atividades
- Page 18 and 19: forma de satisfação de objetivos,
- Page 20 and 21: será inserido não foi modelado e
- Page 22 and 23: Já no Capítulo 4 o estudo compara
- Page 24 and 25: Uma incorreta identificação de re
- Page 26 and 27: a) Requisitos Funcionais (RF): são
- Page 28 and 29: Kotonya e Sommerville (1998) descre
- Page 32 and 33: Informações mais completas a resp
- Page 34 and 35: confirmar teorias ou validar medida
- Page 36 and 37: Sendo o GQM orientado a objetivos o
- Page 38 and 39: No próximo capítulo são apresent
- Page 40 and 41: Essa análise deve ser conduzida an
- Page 42 and 43: Nas seções seguintes, serão apre
- Page 44 and 45: Figura 3.2: Parte de um MO de uma B
- Page 46 and 47: a) Entidade: é alguma coisa do dom
- Page 48 and 49: componentes do Modelo de Objetivos;
- Page 50 and 51: Figura 3.7: Exemplo de parte de um
- Page 52 and 53: mesmo tempo seja capaz de lidar com
- Page 54 and 55: Swimlanes (raias) (Tabela 3.3): fun
- Page 56 and 57: Um exemplo de segmento de processo
- Page 58 and 59: 3.4 A Técnica i*A técnica i*, pro
- Page 60 and 61: Na dependência de tarefa, o Depend
- Page 62 and 63: 3.4.2 O Modelo de Razões Estratég
- Page 64 and 65: observa nas dependências do tipo o
- Page 66 and 67: Os principais elementos do modelo s
- Page 68 and 69: egras refletem políticas do negóc
- Page 70 and 71: IFTHENELSE(sinistro é assegurado p
- Page 72 and 73: alcançar o objetivo-alvo “Realiz
- Page 74 and 75: A especificação de um caso de uso
- Page 76 and 77: Analisando brevemente algumas das t
- Page 78 and 79: Capítulo 4Estudo Comparativo e Ava
- Page 80 and 81:
Figura 4.1: Ciclo de vida de projet
- Page 82 and 83:
solução: desenvolver um sistema d
- Page 84 and 85:
M09: As respostas coletadas de um g
- Page 86 and 87:
Figura 4.2: Diagrama BPMN para o m
- Page 88 and 89:
Figura 4.4: Diagrama SR para o mód
- Page 90 and 91:
Figura 4.6: Diagrama SR para o mód
- Page 92 and 93:
Regra de Negócio 04: REALIZAR PEDI
- Page 94 and 95:
Figura 4.9: Diagrama de Casos de Us
- Page 96 and 97:
No Modelo de Conceitos podem ser vi
- Page 98 and 99:
formuladas, com o intuito de fornec
- Page 100 and 101:
possibilitando também a divisão d
- Page 102 and 103:
sendo inserido. Kaabi, Souveyet e R
- Page 104 and 105:
Para o estudo comparativo foi utili
- Page 106 and 107:
Capítulo 5Considerações FinaisAp
- Page 108 and 109:
de Uso de Negócio não consegue re
- Page 110 and 111:
BIDER, I., JOHANNESSON, P. Tutorial
- Page 112 and 113:
ESTRADA, H., MARTÍNEZ, A., PASTOR,
- Page 114 and 115:
PENADÉS, M. C., CANÓS, J. H., SÁ
- Page 116:
WHITE, S. Business Process Modeling