Um Modelo de Interoperabilidade para Softwares de Gestão de

Transcrição

Tese apresentada à Divisão de Pós-Graduação do Instituto Tecnológico de Aeronáutica como
parte dos requisitos para obtenção do título de Mestre em Ciência no Curso de Pós-Graduação
em Engenharia Eletrônica e Computação na Área de Informática.
Osvandre Alves Martins
Um Modelo de Interoperabilidade
para
Softwares de Gestão de Projetos
Volume 1
Tese aprovada em sua versão final pelos abaixo assinados.
Prof. Dr. Celso Massaki Hirata
Orientador
Prof. Dr. Homero Santiago Maciel
Chefe da Divisão de Pós-Graduação
Campo Montenegro
São José dos Campos, SP - Brasil
2003
para
Composição da Banca Examinadora:
Prof. Dr. Edgar Toshiro Yano
Prof. Dr. Clovis Torres Fernandes
Prof. Dr. José Henrique de Sousa Damiani
Prof. Dr. Jorge Luis Risco Becerra
Presidente – ITA
Orientador – ITA
Membro – ITA
Membro – ITA
Membro Externo – USP-Poli
ITA
i
Dedico este trabalho à memória de minha
avó Geralda e de meu tio Antônio, que em
vida, sempre me agraciaram com seu afeto.
ii
Agradecimentos
A Deus, que diversas vezes iluminou meu caminho e me deu forças para transpor
os obstáculos encontrados durante esta jornada.
A meu orientador, Prof. Celso Massaki Hirata, por ter depositado sua confiança em
minha pessoa, disponibilizado recursos e me conduzido na realização deste trabalho.
Aos Profs. Adilson Cunha, Carlos Henrique, Clovis Fernandes, Damiani, Edgar
Yano e Ney Soma que contribuíram para minha formação por meio das matérias que me
ministraram.
Aos amigos que conheci no ITA, tanto da graduação quanto da pós-graduação, que
estudaram ou trabalharam comigo, me acompanhando nesta jornada.
À minha amiga, Marisa Atsuko Nitto, que me incentivou a iniciar este programa
de mestrado, que agora concluo.
À minha noiva Fabiana, pelo carinho e paciência nos momentos em que não pude
lhe dar a devida e merecida atenção.
Aos meus pais Maria e Vanderlan e meus irmãos Evandro, Rodolfo e Vanderlan
Filho, pelo carinho que sempre me dispensaram.
iii
Resumo
Está se tornando comum que o desenvolvimento de produtos ou serviços seja
realizado conjuntamente por empresas parceiras ou contratadas, que podem estar situadas em
diferentes partes do mundo. Em geral, para entregar o produto ou serviço especificado dentro
do prazo e com o custo planejado, a disciplina de gerência de projetos tem sido empregada.
Esta disciplina consiste de grupos de processos para o inicio, planejamento,
controle, execução e o encerramento de atividades. Geralmente as empresas utilizam
ferramentas computacionais para a realização do trabalho de gerenciamento e é comum
encontrar parceiras de projeto e contratadas utilizando ferramentas distintas que possuem
pouco ou nenhum recurso de integração. Isto resulta em dificuldades na gestão integrada do
projeto e de seus subprojetos, contribuindo para um controle ineficiente, altos custos e
descumprimento de prazos.
Este trabalho endereça os aspectos de interoperabilidade entre softwares de gestão
de projetos, envolvendo um levantamento dos requisitos de comunicação e integração, com
base na metodologia de gestão proposta pelo PMBOK, para propor um modelo de solução em
que estes softwares exponham funcionalidades que possam ser invocadas remotamente, para a
realização de processamentos e troca de dados entre empresas parceiras de projeto.
A tecnologia de serviços Web foi investigada como alternativa para a
implementação da solução proposta devido ao fato de ser baseada em padrões abertos e
tecnologias WWW disponíveis.
A especificação de requisitos foi realizada com base nos conceitos do PMBOK e
em entrevistas com a equipe de gerenciamento de projetos do Programa EMBRAER 170/190.
Estes projetos são desenvolvidos em parceria com várias empresas, e cada uma delas é
responsável pelo desenvolvimento de uma ou mais partes, que compõem os produtos desses
projetos.
O modelo de solução e a tecnologia de serviços Web foram testados e validados
por meio da implementação de dois protótipos de software de gestão de projetos, concebidos a
partir das tecnologias Java e .NET. Eles representam softwares de gestão de projetos de
fabricantes diferentes que trocam dados, propiciando a aplicação da técnica Análise de Valor
Agregado em projetos relacionados.
iv
Abstract
Nowadays the development of products or services, performed jointly by
partnerships or hired companies which are located in different parts of the world, is becoming
common. In order to deliver the specified product service on time and within the planned cost
, the discipline of the project management has been widely employed.
This discipline consists of many group processes to start, plan, control, execute
and conclude the activities. Computational tools have been used as an aid to manage these
activities and it is common to find project partners which use distinct tools with a few or no
integration resources. It results in difficulties related to the integrated management of the
project contributing to an inefficient control, high costs and deadline delay.
This dissertation addresses the aspects of the interoperability between the
management software of projects, involving a survey of the communication requirements
based on PMBOK methodology to propose a model of solution in which this software
exposes the functionality that can be remotely invoked to perform computing and data
exchange among the project partners.
The web service technology was investigated as an alternative to implement the
solution proposed because it is based on open standards and WWW technology already
available.
The requirements specification was made based on PMBOK concepts and on
interviews with the project management team from EMBRAER 170/190 Program. This
program is a set of projects that involves many enterprises, and each one is responsible for the
development of the components that will be integrated to the final product.
The model of solution and Web service technology were tested and validated by
implementing two software prototypes using Java and .NET technologies. They represent the
project management software from different manufacturers that interchange data allowing the
Earned Value Analyses technique application on related projects.
v
Sumário – Volume 1
Agradecimentos........................................................................................................................................ ii
Resumo ................................................................................................................................................... iii
Abstract ................................................................................................................................................... iv
Lista de Ilustrações ............................................................................................................................... viii
Lista de Tabelas .......................................................................................................................................x
Lista de Abreviaturas e Siglas................................................................................................................. xi
Capítulo I ....................................................................................................................1
Introdução................................................................................................................................................ 1
1.1
Motivação.............................................................................................................................................. 1
1.2
Objetivos ............................................................................................................................................... 2
1.3
Escopo do Trabalho ............................................................................................................................... 2
1.4
Resumo dos Próximos Capítulos ........................................................................................................... 3
Capítulo II ...................................................................................................................5
A Gestão de Projetos e Projetos de Larga Escala Envolvendo Empresas Parceiras ............................ 5
2.1
Definições e Conceitos da Gestão de Projetos....................................................................................... 5
2.1.1
Processos e Grupos de Processos de Projetos ............................................................................. 6
2.1.2
Envolvidos e Interessados no Projeto ......................................................................................... 8
2.1.3
As Áreas de Conhecimento do Gerenciamento de Projetos........................................................ 8
2.1.4
Estrutura Analítica de Projeto................................................................................................... 11
2.1.5
Relato do Desempenho de Projetos .......................................................................................... 12
2.2
Projetos de Larga Escala Envolvendo Empresas Parceiras ................................................................. 21
2.3
Um exemplo de Projeto de Larga Escala que Envolve Parceiros ........................................................ 23
2.4
Ferramentas Computacionais de Apoio à Gestão de Projetos ............................................................. 27
2.4.1
Ferramentas de Apoio à Especificação, Análise e Controle de Requisitos............................... 28
2.4.2
Ferramentas de Apoio ao Planejamento e Monitoramento de Projetos .................................... 29
2.4.3
Ferramentas de Apoio à Comunicação e ao Trabalho Cooperativo .......................................... 32
2.4.4
Ferramentas de Apoio à Gestão Empresarial ............................................................................ 34
2.4.5
Ferramentas de Apoio ao Controle de Versões e Gerência de Configuração ........................... 35
2.5
Resumo do Capítulo e Alguns Comentários........................................................................................ 36
Capítulo III ................................................................................................................37
O Software como Serviço...................................................................................................................... 37
3.1
Sistemas Distribuídos e os Serviços Web............................................................................................ 37
3.2
Conceituação de Serviços Web ........................................................................................................... 40
3.3
Tecnologias de Suporte aos Serviços Web .......................................................................................... 43
3.3.1
A Linguagem de Marcação Estendida - XML .......................................................................... 45
3.3.2
O Protocolo de Comunicação SOAP ........................................................................................ 48
3.3.3
A Linguagem de Descrição de Serviços Web – WSDL............................................................ 51
3.3.4
O Serviço de Publicação de Serviços Web – UDDI ................................................................ 57
vi
3.4
Arquiteturas de Aplicativos e Interação de Serviços Web................................................................... 61
3.5
A Arquitetura Global para Serviços Web em XML – GXA................................................................ 66
3.5.1
Segurança em Serviços Web..................................................................................................... 68
3.5.2
Transações em Serviços Web ................................................................................................... 69
3.5.3
Coordenação de Processos de Serviços Web ............................................................................ 69
3.5.4
Mensagens Confiáveis entre Serviços Web .............................................................................. 70
3.5.5
Roteamento e Referência de Serviços Web .............................................................................. 70
3.5.6
Anexos em Mensagens de Serviços Web.................................................................................. 71
3.6
Desempenho de Serviços Web ............................................................................................................ 72
3.7
Conceitos no Desenvolvimento de Serviços Web ............................................................................... 74
3.7.1
Fases do Ciclo de Desenvolvimento de Serviços Web ............................................................. 74
3.7.2
Abordagens para o Desenvolvimento de Serviços Web ........................................................... 76
3.8
Plataformas de Desenvolvimento de Serviços Web ............................................................................ 78
3.9
Serviços Web na Plataforma J2EE ...................................................................................................... 79
3.9.1
O Padrão ebXML...................................................................................................................... 81
3.9.2
Servlets ..................................................................................................................................... 82
3.9.3
Java Server Pages...................................................................................................................... 82
3.9.4
Java Beans e Enterprise Java Beans.......................................................................................... 83
3.9.5
Conectores J2EE ....................................................................................................................... 85
3.10
Serviços Web na Plataforma Microsoft .NET ..................................................................................... 86
3.11
Resumo do Capítulo e Resultados Obtidos.......................................................................................... 88
Capítulo IV................................................................................................................90
Uma Proposta de Solução de Interoperabilidade para a Gestão de Projetos de Larga Escala
Envolvendo Empresas Parceiras .......................................................................................................... 90
4.1
Utilização de um Processo de Desenvolvimento de Software ............................................................. 90
4.2
Uma Visão do Problema e o Modelo de Solução Proposto ................................................................. 96
4.3
Um Plano para o Gerenciamento de Requisitos ................................................................................ 100
4.4
Especificação de Requisitos Funcionais ............................................................................................ 101
4.5
Especificação de Requisitos Não Funcionais .................................................................................... 105
4.6
Resumo do Capítulo e Resultados Obtidos........................................................................................ 105
Capítulo V...............................................................................................................107
Protótipos de Software de Gestão de Projetos Interoperáveis ........................................................... 107
5.1
Finalidade e Escopo dos Protótipos................................................................................................... 107
5.2
Principais Interfaces de Usuário ........................................................................................................ 110
5.3
Detalhes da Arquitetura ..................................................................................................................... 120
5.3.1
A Camada de Acesso a Dados (persistence) ........................................................................... 123
5.3.2
A Camada de Entidades de Negócio (business)...................................................................... 126
5.3.3
A Camada de Controle de Fluxos de Casos de Uso (control) ................................................. 129
5.3.4
A Camada de Serviços (services)............................................................................................ 131
5.3.5
A Camada de Apresentação (presentation) ............................................................................. 134
vii
5.4
Detalhes da Implementação do Serviço Web .................................................................................... 136
5.4.1
O Serviço Web de Relato de Desempenho ............................................................................. 137
5.4.2
Consumidores do Serviço Web de Relato de Desempenho .................................................... 139
5.5
Cenário de Testes .............................................................................................................................. 141
5.6
Capítulo VI..............................................................................................................151
Conclusões, Contribuições e Sugestões de Trabalhos Futuros ......................................................... 151
6.1
Conclusões......................................................................................................................................... 151
6.2
Contribuições..................................................................................................................................... 152
6.3
Sugestões de Trabalhos Futuros ........................................................................................................ 152
Referências Bibliográficas ...................................................................................154
Glossário................................................................................................................158
Apêndice 1
Visão (Conforme Modelo do RUP)...................................................................................................... 165
Apêndice 2
Glossário (Conforme Modelo do RUP) ............................................................................................... 176
Apêndice 3
Plano de Gerenciamento de Requisitos (Conforme Modelo do RUP)................................................ 183
Apêndice 4
Considerações e Requisitos de Serviços Web para Projetos de Larga Escala Envolvendo Empresas
Parceiras ............................................................................................................................................. 193
Apêndice 5
Especificações Suplementares (Conforme Modelo do RUP) ............................................................. 221
Apêndice 6
Relação Analítica de Requisitos.......................................................................................................... 227
viii
Lista de Ilustrações
Figura 1: Grupos de Processos da Gestão de Projetos............................................................................................. 7
Figura 2 : Exemplo de Estrutura Analítica de Projeto ........................................................................................... 12
Figura 3: Estabelecimento da Linha de Base do Projeto. ...................................................................................... 13
Figura 4: Monitoramento de Índices de Desempenho ........................................................................................... 15
Figura 5: Gráfico com Elementos da Análise de Valor Agregado. ....................................................................... 18
Figura 6: Relacionamento entre Empresas Parceiras e Contratadas. ..................................................................... 22
Figura 7: EMBRAER 170/190 - Parceiros do Programa....................................................................................... 24
Figura 8: EMBRAER 170/190 - Intranet para Comunicação com Parceiros do Programa. .................................. 25
Figura 9: Escritório do Projeto e Time do Projeto................................................................................................. 26
Figura 10: Exemplo de Sistema Distribuído.......................................................................................................... 38
Figura 11: Papéis e Operações no Contexto dos Serviço Web.............................................................................. 42
Figura 12: Estrutura Básica dos Serviços Web...................................................................................................... 44
Figura 13: Exemplo de um Documento XML Evidenciando sua Estrutura Básica............................................... 45
Figura 14: Exemplo de um Documento DTD........................................................................................................ 46
Figura 15: Exemplo de Documento XSD.............................................................................................................. 47
Figura 16: Estrutura Básica de uma Mensagem SOAP. ........................................................................................ 49
Figura 17: Exemplo de Definição de uma Mensagem SOAP para Requisição de um Serviço Web..................... 50
Figura 18: Exemplo de Definição de uma Mensagem SOAP em Resposta à Solicitação de um Serviço Web..... 50
Figura 19: Estrutura de um Documento WSDL. ................................................................................................... 54
Figura 20: Estrutura da Dados de um Registro UDDI de uma businesEntity........................................................ 59
Figura 21: Exemplo Abstrato de um Registro UDDI de Serviço de Negócio (businessService). ........................ 59
Figura 22: Exemplo Abstrato de um Registro UDDI tModel............................................................................... 60
Figura 23: Proposta de Arquitetura para Aplicativos Orientados a Serviço. ......................................................... 62
Figura 24: Integração de Aplicativos Construídos em Arquiteturas Orientadas a Serviço.................................... 63
Figura 25: Interação Síncrona de Serviço Web ..................................................................................................... 65
Figura 26: A Arquitetura Global de Serviços Web em XML (GXA).................................................................. 67
Figura 27: Fases do Ciclo de Desenvolvimento de Serviços Web. ....................................................................... 76
Figura 28: Ambiente de Execução de Serviços Web Baseado em J2EE ............................................................... 80
Figura 29: Ambiente de Execução de Serviços Web Baseado na Arquitetura .NET............................................. 87
Figura 30: Visão Geral do Processo Unificado Rational....................................................................................... 94
Figura 31: O Modelo de Interoperabilidade para Softwares de Gestão de Projetos. ............................................. 97
Figura 32: WS4PM – Serviços Web para a Gestão de Projetos. ........................................................................... 98
Figura 33: Estratégia Utilizada para Especificação de Requisitos dos WS4PM. .................................................. 99
Figura 34: Rastreabilidade de Requisitos dos WS4PM. ...................................................................................... 101
Figura 35 : Exemplo de Ficha Contendo Considerações e Levantamento Inicial de Requisitos........................ 104
Figura 36: JavaPMSWeb - Diagrama de Casos de Uso....................................................................................... 109
Figura 37: JavaPMSWeb - Interface de Usuário Principal.................................................................................. 111
Figura 38: JavaPMSWeb - Edição de Dados de Empresas Parceiras. ................................................................. 112
Figura 39: JavaPMSWeb - Manutenção de Registros de Empresas Parceiras..................................................... 113
Figura 40: JavaPMSWeb - Acesso à Definição ou Manutenção de Projetos. ..................................................... 113
Figura 41: JavaPMSWeb - Definição de Projeto................................................................................................. 114
Figura 42: JavaPMSWeb - Definição da WBS de Projeto. ................................................................................. 115
Figura 43: JavaPMSWeb - Planejamento e Relatos de Desempenho.................................................................. 117
Figura 44: JavaPMSWeb - Gráfico da Análise de Valor Agregado. ................................................................... 118
Figura 45: JavaPMSWeb - Análise de Valor Agregado - Valores Correntes e Acumulados. ............................. 118
ix
Figura 46: JavaPMSWeb - Análise de Valor Agregado - Variações e Índices de Desempenho. ........................ 119
Figura 47: JavaPMSWeb - Análise de Valor Agregado – Estimativas para Conclusão. ..................................... 119
Figura 48: JPMSClient - Interface do Software que Interopera com o JavaPMSWeb. ....................................... 120
Figura 49: JavaPMSWeb - Camadas do Software............................................................................................... 122
Figura 50: JavaPMSWeb - Diagrama de Classes da Camada de Acesso a Dados. ............................................. 124
Figura 51: JavaPMSWeb - Elemento Raiz do Arquivo XML de Configuração do Software. ............................ 124
Figura 52: JavaPMSWeb - Elemento Raiz da Porção de Configuração de Acesso a Dados............................... 125
Figura 53: JavaPMSWeb - Elemento de Configuração de um SGBDR Específico. ........................................... 125
Figura 54: JavaPMSWeb - Elemento de Configuração de Mapeamento de Códigos de Erro............................. 126
Figura 55: JavaPMSWeb - Diagrama de Classes da Camada de Entidades de Negócio. .................................... 127
Figura 56: JavaPMSWeb - Classes da Camada de Controle de Fluxo de Casos de Uso. .................................... 131
Figura 57: JavaPMSWeb - Diagrama de Classes Envolvendo a Classe Exposta como WS4PM........................ 132
Figura 58: JavaPMSWeb - Diagrama de Classes Envolvendo Classes Consumidoras do WS4PM Implementado.
................................................................................................................................................................... 133
Figura 59: JavaPMSWeb - Estrutura de Diretórios Referente à Camada de Apresentação e o Contêiner do
Servidor de Aplicações .............................................................................................................................. 134
Figura 60: JavaPMSWeb - Diagrama de Instalação. ........................................................................................... 136
Figura 61: Registro UDDI do WS4PM Implementado. ...................................................................................... 139
Figura 62: A Classe Consumidora (Proxy) do WS4PM Implementado. ............................................................. 140
Figura 63: Cenário de Testes dos Protótipos de Software Desenvolvidos. ......................................................... 142
Figura 64: Interface da Ferramenta "TCP Monitor". ........................................................................................... 144
Figura 65 : Mensagem SOAP de Invocação do WS4PM Implementado. ........................................................... 145
Figura 66: Mensagem SOAP de Resposta à Invocação do WS4PM Implementado. .......................................... 146
Figura 67: JavaPMSWeb - Diagrama de Seqüência da Invocação de WS4PM de Relato de Desempenho....... 147
Figura 68: JavaPMSWeb - Diagrama de Seqüência de Processamento da Invocação do WS4PM de Relato de
Desempenho............................................................................................................................................... 148
x
Lista de Tabelas
Tabela 1: Mapeamento de Processos em Grupos e Áreas de Conhecimento. ....................................................... 10
Tabela 2: Variáveis da Análise de Valor Agregado. ............................................................................................. 17
Tabela 3: Exemplos de Groupware. ...................................................................................................................... 33
Tabela 4: Modelos de Serviços Web ..................................................................................................................... 64
Tabela 5: Abordagens para Desenvolvimento de Serviços Web. .......................................................................... 76
Tabela 6: Tecnologias .NET e J2EE para Serviços Web....................................................................................... 79
Tabela 7: Abrangência das Considerações e Requisitos de Interoperabilidade entre Parceiros de Projetos. ...... 103
xi
Lista de Abreviaturas e Siglas
API - Application Programming Interface: Interface de Programação de Aplicação.
B2B – Business To Business: Negócio a Negócio.
B2Bi – Business To Business Integration: Integração de sistemas Negócio a Negócio.
B2C – Business To Consumer: Negócio a Consumidor.
B2Ci – Business To Consumer Integration: Integração Negócio a Consumidor.
CORBA - Common Object Request Broker Architecture.
CLR – Common Language Runtime: Ambiente comum de execução de linguagens.
DCOM – Distributed Component Object Model: Modelo de Componentes de Objetos
Distribuídos.
EAI - Enterprise Application Integration: Integração de Aplicações Empresariais.
EAP – Estrutura Analítica do Projeto: Veja WBS.
ebXML – electronic business eXtensible Markup Language: Linguagem de marcação
estendida para comércio eletrônico.
ERP – Enterprise Resource Planning: Planejamento de Recurso Empresarial (Sistema).
GXA – Global XML Architecture: Arquitetura Global para XML.
HTTP – Hipertext Transfer Protocol: Protocolo de Transporte de Hipertexto.
HTTPS - Hipertext Transfer Protocol Secure: Protocolo de Transporte Seguro de Hipertexto.
IDL – Interface Definition Language: Linguagem de Definição da Interface.
IIOP – Internet Inter-ORB Protocol: Protocolo Inter-ORB de Internet.
J2EE – Java To Enterprise Edition: Edição Empresarial do Java.
JMS – Java Messaging Service: Serviço de Mensagens Java.
JNDI – Java Naming and Directory Interface: Interface de Diretórios e Nomes Java.
JTA – Java Transaction API: Interface de Programação de Aplicação para Transação Java.
JTS – Java Transaction Service: Serviço de Transação Java.
JVM – Java Virtual Machine: Máquina Virtual Java.
JDK – Java Development Kit: Kit de Desenvolvimento em Java.
LSP - Large Scale Projects – LSP: Projetos de Larga Escala – PLE.
MIME - Multipurpose Internet Mail Extension: Extensão de correio de Internet de propósito
múltiplo.
ORB – Object Request Broker: Corretor de Pedido de Objeto.
PLE – Projetos de Larga Escala: Large Scale Projects – LSP.
PMI – Project Management Institute: Instituto de Gerenciamento de Projeto.
PMBOK – Project Management Body Of Knowledge: Corpo de Conhecimento de
Gerenciamento de Projeto.
xii
QoS – Quality of Service: Qualidade de Serviço.
RMI – Remote Method Invocation: Invocação Remota de Método.
RUP – Rational Unified Process: Processo Unificado Rational.
SOAP – Simple Object Access Protocol: Protocolo simples de acesso a objetos.
SGP – Software de Gestão de Projetos.
tModel – Unidade de registro de um serviço Web em um serviço de registro UDDI.
UDDI – Universal Description, Discover and Integration: Descrição, Descoberta e Integração
Universal.
UML - Unified Modeling Language: Linguagem de Modelagem Unificada.
URI – Uniform Resource Identifier: Identificador de Recurso Uniforme.
URL – Uniform Resource Locator: Localizador de Recurso Uniforme.
WBS – Work Breakdown Structure: Estrutura Analítica do Projeto – EAP, também
referenciada como Estrutura de Decomposição do Trabalho - EDT.
WS4PM – Web Services For Project Management: Serviços Web para a Gestão de Projetos.
WSDL – Web Service Description Language: Linguagem de Descrição de Serviço Web.
WWW – World Wide Web: Rede mundial de computadores
XML – eXtensible Markup Language: Linguagem de Marcação Estendida.
1
1 Capítulo I
Introdução
1.1 Motivação
No mundo globalizado, o desenvolvimento de projeto de um novo produto ou
serviço mais complexo geralmente conta com a colaboração de diversos parceiros. Pode-se
tomar como exemplos, as montadoras de automóveis, as quais, para o desenvolvimento de um
novo modelo, várias empresas fornecedoras são envolvidas e, a partir de especificações de
projeto, produzem peças que comporão o referido produto. Além das montadoras de
automóveis, podem-se citar várias outras indústrias, dos mais diversos segmentos, que
trabalham de maneira análoga, tais como, por exemplo, as indústrias de aeronáutica, de
computadores, e de eletrodomésticos.
Os processos da gestão de projetos dependem, por exemplo, de reuniões periódicas
para definições de prazos e tarefas, avaliações, resolução de conflitos e negociação. Na grande
maioria das vezes, o escopo geográfico dos parceiros envolvidos é global. Com isso, tempo e
custo para realizar projetos desse tipo tornam-se críticos.
Para esse fim, sistemas de comércio eletrônico como os do tipo B2B (Business To
Business) têm tentado trazer algum suporte. Várias ferramentas informatizadas de apoio à
gestão de projetos estão disponíveis no mercado, permitindo a realização de diversas
operações sobre a Internet, inclusive suporte ao trabalho cooperativo.
Em geral, as
finalidades desses sistemas são, por exemplo, a diminuição de custos de operações e redução
de tempo de execução de tarefas relacionadas com o design do produto e gestão de projeto.
Contudo, a grande diversidade de fornecedores de ferramentas desse tipo traz
como conseqüência uma certa dificuldade de integração entre os parceiros de projeto, que
nem sempre utilizam a mesma solução informatizada. Desta forma, deparam-se com
2
problemas relacionados com a necessidade de controlar internamente seus processos e,
simultaneamente, ter que compartilhar informações pertinentes com os demais interessados.
Cada fornecedor de software e soluções B2B, destinados a auxiliar as empresas nesse tipo de
aplicação, utiliza-se de tecnologias específicas e, na maioria das vezes distintas, apresentando
particularidades de implementação e utilização.
Nesses sistemas, aspectos de segurança, como autenticação, integridade,
autorização e confidencialidade, são relevantes no sentido de que cada parceiro geralmente
limita as informações que podem transpor as fronteiras de sua organização.
1.2 Objetivos
Este trabalho tem, basicamente, dois objetivos. O primeiro deles é investigar a
gestão de projetos na perspectiva de projetos de larga escala envolvendo empresas parceiras,
para especificar um conjunto de requisitos de comunicação e integração para propiciar o
desenvolvimento integrado de projetos relacionados. O segundo objetivo, decorrente do
primeiro, refere-se à investigação da tecnologia de serviços Web (Web Services) como
alternativa para a implementação de uma solução que atenda a estes requisitos e possa vir a
ser implementada em softwares de gestão de projetos.
1.3 Escopo do Trabalho
Este trabalho envolve a investigação de conceitos de gerenciamento de projetos
necessários à conceituação da gestão de projetos de larga escala envolvendo parceiros e ao
embasamento para desenvolvimento do modelo de solução proposto e de um estudo de caso
que valida este modelo.
A tecnologia de serviços Web é descrita de forma a propiciar o entendimento dos
conceitos, tecnologias correlatas, aspectos de implementação, arquitetura, instalação,
publicação, descoberta e utilização de serviços de software, sem entrar em detalhes de
programação em linguagens específicas.
Os requisitos de interoperabilidade, relacionados com a gestão de projetos que
envolvem empresas parceiras, foram especificados com base em necessidades apontadas por
profissionais da equipe de projetos do Programa EMBRAER 170/190, especificações
3
relacionadas a serviços Web e conceitos de gerenciamento de projetos constantes no PMBOK
(PMI, 2000). Desta forma, estão sendo considerados, neste trabalho, apenas a metodologia de
gestão de projetos proposta pelo PMBOK e a interoperabilidade entre softwares de gestão de
projetos que implementam funcionalidades relacionadas a esta metodologia. Vale ressaltar
que os requisitos especificados estão sujeitos a revisões, refinamentos e detalhamentos
quando tratados em tempo de design, implementação e testes da solução proposta.
Dois protótipos de software de gestão de projetos são implementados com a
finalidade de desenvolver um Estudo de Caso que mostre a viabilidade tanto do modelo de
solução proposto neste trabalho, quanto da tecnologia em investigação, que é a dos serviços
Web. Sendo assim, não são implementadas funcionalidades relacionadas com aspectos de
segurança, autenticação, políticas de autorização e controle de transações, sendo estas,
deixadas como sugestões para tratamento em trabalhos específicos que podem ser
desenvolvidos futuramente.
1.4 Resumo dos Próximos Capítulos
O Capítulo II faz uma breve referência aos conceitos básicos da gestão de projetos
apresentando as principais definições. Além disso, são apresentados aspectos da gestão de
projetos de larga escala envolvendo empresas parceiras, fornecendo inclusive, um exemplo
desse tipo de projeto. Um conjunto de ferramentas computacionais, que são utilizadas no
auxílio ao desenvolvimento das atividades de gerência de projetos, também é apresentado e
comentado, mostrando a finalidade e utilização de cada uma neste contexto.
No Capítulo III, a tecnologia de serviços Web é conceituada de forma que suas
principais características, tecnologias correlatas, arquiteturas e padrões são apresentados e
comentados. Além disso, os principais conceitos relacionados com o desenvolvimento de
serviços Web são apresentados, descrevendo-se as formas principais empregadas na
construção, instalação, execução e gerenciamento de unidades de software que implementam
estes serviços. A implementação de serviços Web é apresentada com base nas duas principais
plataformas de desenvolvimento de software que suportam seu desenvolvimento. Detalhes
sobre estas plataformas são apresentados possibilitando uma comparação entre elas.
O conteúdo do Capítulo IV é norteado pelo processo de desenvolvimento de
software adotado. Nele, uma visão mais detalhada do objetivo principal deste trabalho é
apresentada, juntamente com uma proposta de solução. Além disso, é proposto um plano para
4
gerenciamento dos requisitos funcionais e não funcionais da solução, que foram especificados
e validados por meio de entrevistas realizadas com profissionais da Empresa Brasileira de
Aeronáutica S/A – EMBRAER.
No Capítulo V são apresentados os detalhes da implementação dos protótipos de
software desenvolvidos para testar e validar a solução tecnológica proposta. Dentre esses
detalhes estão as principais interfaces de usuário, a arquitetura de software projetada, detalhes
da implementação de serviços Web, o cenário de testes e as principais tecnologias utilizadas.
O Capítulo VI apresenta as conclusões deste trabalho, ressaltando as contribuições
mais importantes e sugestões para trabalhos futuros.
O Apêndice 1 é o documento Visão. Ele é o artefato proposto pelo processo de
desenvolvimento de software utilizado, que define o problema endereçado num projeto de
software, apresenta os principais envolvidos e interessados, suas principais necessidades, e
uma proposta de solução.
O Apêndice 2 é um exemplo de artefato intitulado Glossário que é utilizado em
projetos de desenvolvimento de software para estabelecimento de um vocabulário comum e
familiarização da equipe de projeto com termos relacionados com o domínio da aplicação.
O Apêndice 3 representa a proposta de um plano para o gerenciamento dos
requisitos especificados. Este plano é necessário para se estabelecer a forma como os
requisitos serão gerenciados num projeto de desenvolvimento de software.
O Apêndice 4 é o documento intitulado “Considerações e Requisitos de Serviço
Web para Projetos de Larga Escala Envolvendo Empresas Parceiras”. Ele foi desenvolvido no
intuito de se especificar requisitos funcionais para a solução proposta.
O Apêndice 5 é o artefato que possui a finalidade de registrar requisitos não
funcionais, também conhecidos como Especificações Suplementares para a solução proposta.
O Apêndice 6 é um relatório, emitido a partir da ferramenta de apoio à gerência de
requisitos utilizada, que apresenta uma análise de todos os requisitos especificados para a
solução proposta. Nele, os requisitos funcionais, oriundos do Apêndice 4, e os requisitos não
funcionais, oriundos do Apêndice 5, são apresentados conforme definições contidas no
Apêndice 3, que propõe uma forma de gerenciar esses requisitos com base em tipos de
requisitos, atributos desses tipos, e itens de rastreabilidade que permitem conhecer a origem e
o impacto dos requisitos na solução proposta.
5
2 Capítulo II
A Gestão de Projetos e Projetos de Larga
Escala Envolvendo Empresas Parceiras
Neste capítulo são apresentados, de maneira sucinta, as principais definições e
conceitos relacionados com o gerenciamento de projetos. São também apresentadas
considerações e um exemplo de projeto de larga escala que envolve parceiros, propiciando a
fundamentação e conceituação necessárias para o entendimento do contexto em que se insere
esse trabalho. Além disso, algumas ferramentas computacionais, atualmente utilizadas no
auxílio a profissionais da área, são descritas e comentadas.
2.1 Definições e Conceitos da Gestão de Projetos
O PMBOK (PMI, 2000) define projeto como um empreendimento temporário com
o objetivo de criar um produto ou serviço único. É temporário porque tem um começo, meio e
fimz bem determinados. Único porque o produto ou serviço produzido é, de alguma forma,
diferente de todos os outros produtos ou serviços produzidos anteriormente.
De forma um pouco mais técnica, Kerzner (1997) define projeto como “um
conjunto de tarefas e atividades executadas de forma coordenada, em que são alocados os
insumos necessários para, num dado prazo, atingir um objetivo. Este objetivo geralmente é
especificado em termos de custos, tempo e desempenho”.
Para que se tenha um melhor controle, pode-se dividir os projetos em fases,
constituindo o chamado ciclo de vida do projeto. Cada fase do projeto é definida pela
conclusão de um ou mais produtos da fase, conhecidos como deliverables. Um deliverable é
um produto tangível e verificável resultante de um trabalho, como por exemplo, um estudo de
viabilidade, um projeto lógico detalhado ou um protótipo (PMI, 2000).
6
A conclusão de uma fase do projeto é caracterizada pela revisão dos trabalhos e
dos padrões de desempenho, para determinar se o projeto terá continuidade e detectar e
corrigir desvios.
Os produtos oriundos de uma fase normalmente são aprovados antes do início da
próxima fase. Entretanto, quando os riscos são considerados aceitáveis, a fase subseqüente
pode iniciar antes da aprovação destes. Esta prática de sobreposição é conhecida como fast
tracking (PMI, 2000).
Nas próximas subseções apresentam-se os principais conceitos e elementos da
gestão de projetos, relacionados com os objetivos deste trabalho.
2.1.1
Processos e Grupos de Processos de Projetos
O PMBOK (PMI, 2000) define processo como uma série de ações, executadas por
pessoas, que geram resultados. Os projetos são geridos e realizados por estes processos, que
geralmente se enquadram em duas categorias:
•
Processos da gerência de projetos – São aqueles que se relacionam
com a descrição, a organização e a conclusão do trabalho do projeto; e
•
Processos orientados a produto – São aqueles que se relacionam com
a especificação e a criação do produto do projeto.
Durante todo o desenvolvimento do projeto os processos destas duas categorias se
interagem e se sobrepõem. Um exemplo está no fato de que o escopo do projeto não pode ser
definido sem algum conhecimento básico de como o produto deve ser criado.
O PMBOK (PMI, 2000) sugere o agrupamento dos processos da Gestão de
Projetos em cinco grupos distintos. A Figura 1 ilustra esses grupos bem como o
relacionamento entre eles. As setas entre as caixas que representam os grupos de processos
indicam o fluxo das informações que estabelecem o relacionamento entre eles. Os grupos de
processos apresentados são os seguintes:
•
Processos de iniciação – Determinam o início do projeto ou de uma
fase;
•
Processos de planejamento - Planejam e se organizam o trabalho para
cumprir as necessidades do projeto ou da fase;
7
•
Processos de execução – Referem-se à realização dos trabalhos;
•
Processos de controle - Têm por objetivo ajustar o realizado, durante a
execução, com o planejado; e
•
Processos de encerramento – Relacionam-se à aprovação formal da
fase ou do projeto, na qual se encerram as atividades, realocando-se os
recursos.
Figura 1: Grupos de Processos da Gestão de Projetos.
Cada um dos processos pode ser descrito em termos de suas entradas, ferramentas
e técnicas e, saídas. Definem-se como entradas, os documentos ou itens documentáveis que
influenciarão o processo. As ferramentas e técnicas são aplicados às entradas no intuito de se
obter as saídas desejadas, que são documentos ou itens documentáveis resultantes do
processo. Com isso tem-se a interação entre os processos em que as saídas de um podem ser
utilizadas como entradas em outros (PMI, 2000).
Os recursos de software devem apoiar a integração entre os processos da gestão de
projetos utilizados pelas diversas parceiras. A Tabela 1 lista os processos e aloca-os em seus
respectivos grupos. Detalhes sobre os processos podem ser obtidos no PMBOK (PMI, 2000).
8
2.1.2
Envolvidos e Interessados no Projeto
Em um projeto, as pessoas ou organizações envolvidas diretamente, ou aquelas
cujos interesses podem ser afetados de maneira positiva ou negativa com o resultado de sua
execução, são conhecidas como stakeholders. A equipe de gerenciamento do projeto deve
identificar os stakeholders, determinar quais são suas expectativas e necessidades e então
gerenciar e influenciar estas expectativas para se alcançar o sucesso do projeto (PMI, 2000).
Normalmente o processo de identificação dos stakeholders é difícil, mas alguns
elementos podem ser levados em consideração para a execução desta tarefa. Aqui estão
alguns dos prováveis candidatos à condição de stakeholder do projeto:
•
Gerente do projeto - Indivíduo responsável pelo gerenciamento do
projeto.
•
Cliente - Pessoa ou organização que irá utilizar o produto resultante do
projeto.
•
Patrocinador - Pessoa ou grupo de dentro da organização ou não, que
provê os recursos financeiros para a execução do projeto.
Podem existir diferentes nomes e categorias de stakeholders – internos ou
externos, proprietários ou fundadores, fornecedores ou contratantes, membros da equipe e
seus familiares, agências governamentais ou meios externos, indivíduos, organizações
temporárias ou permanentes e a sociedade de um modo genérico.
Os papéis e responsabilidades atribuídos a stakeholders podem se sobrepor em
muitos casos, como por exemplo, quando uma empresa de desenvolvimento de sistemas
proporciona os recursos financeiros para um sistema de informação que ela própria está
desenvolvendo (PMI, 2000).
2.1.3
As Áreas de Conhecimento do Gerenciamento de
Projetos
Segundo o PMBOK (PMI, 2000), as áreas de conhecimento do gerenciamento de
projetos descrevem os conhecimentos e práticas em termos dos processos que as compõem.
Foram definidas as seguintes 9 (nove) áreas de conhecimento:
9
•
Gestão de Integração – Inclui os processos necessários para assegurar
que os elementos do projeto estejam coordenados apropriadamente;
•
Gestão do Escopo - Inclui todos os processos necessários para garantir
que o projeto contenha todo o trabalho necessário, e somente o trabalho
necessário, para completá-lo com sucesso;
•
Gestão do Tempo - Inclui os processos necessários para assegurar a
conclusão dos trabalhos no prazo planejado;
•
Gestão de Custo - Inclui os processos necessários para assegurar que o
projeto será completado com as metas de custo e orçamento planejados;
•
Gestão da Qualidade - Contém os processos necessários para assegurar
e satisfazer as necessidades empreendidas no projeto;
•
Gestão de Recursos Humanos - Inclui processos que visam otimizar a
utilização dos recursos humanos envolvidos no projeto;
•
Gestão de Comunicação – Envolve os processos necessários para
assegurar
a
geração,
coleta,
disseminação,
armazenamento
e
disponibilização das informações no tempo certo, de forma adequada e
atualizada;
•
Gestão de Riscos - Inclui os processos para identificar, analisar e
responder pelo risco do projeto; e
•
Gestão de Aquisições - Inclui os processos para aquisição de recursos e
serviços de terceiros.
A Tabela 1, extraída de (PMI, 2000), apresenta um mapeamento dos processos em
grupos e área de conhecimento. São ao todo 39 (trinta e nove) processos, sendo que a maioria
se enquadra no grupo de processos de planejamento.
10
Tabela 1: Mapeamento de Processos em Grupos e Áreas de Conhecimento.
Grupos de
Processos
Iniciação
Planejamento
Execução
Controle
1-Desenvolvimento do
Plano do Projeto
1-Execução do
Plano do Projeto
1-Controle
Integrado de
Mudanças
Encerramento
Áreas de
Conhecimento
Gestão da
Integração
Gestão do
Escopo
Gestão do
Tempo
1-Iniciação
1-Planejamento do
Escopo
1-Verificação do
Escopo
2-Definição do Escopo
2-Controle de
Mudanças
1-Definição das
Atividades
1-Controle do
Cronograma
2-Sequenciamento das
Atividades
3-Estimativa de
Duração das
Atividades
4-Desenvolvimento do
Cronograma
Gestão do
Custo
1-Planejamento dos
Recursos
1-Controle de
custos
2-Estimativa dos
custos
3-Orçamento dos
custos
Gestão da
Qualidade
1-Planejamento da
qualidade
1-Garantia da
qualidade
Gestão de
Recursos
Humanos
1-Planejamento
organizacional
1Desenvolvimento
da equipe
2-Montagem da equipe
1-Planejamento da
gestão de riscos
1-Controle da
qualidade
1-Controle e
monitoração dos
riscos
2-Identificação dos
riscos
3-Análise qualitativa
dos riscos
Gestão de
Riscos
4-Análise quantitativa
dos riscos
5-Planejamento de
resposta aos riscos
Gestão da
Comunicação
Gestão de
Aquisições
1-Planejamento das
comunicações
1-Distribuição das
informações
1-Planejamento das
aquisições
1-Pedido de
propostas
2-Preparação das
aquisições
2-Seleção de
fornecedores
3-Administração
dos contratos
1-Relato de
desempenho
1-Encerramento
administrativo
1-Encerramento
dos contratos
11
2.1.4
Estrutura Analítica de Projeto
A Estrutura Analítica de um Projeto – EAP, referenciada em inglês como WBS
(Work Breakdown Structure), é definida pelo PMBOK (PMI, 2000) como sendo o
agrupamento de componentes do projeto (orientado para a elaboração de subprodutos) que
organiza e define seu escopo.
Segundo o PMBOK (PMI, 2000), o trabalho que não consta na WBS está fora do
escopo do projeto e a principal função desta estrutura é criar ou ratificar o entendimento
comum desse escopo. Ela é produto do processo de Definição do Escopo da Área de
Gestão de Escopo.
Valeriano (1998) traduz WBS como EDT (Estrutura de Decomposição do
Trabalho) e diz que ela consiste numa criteriosa decomposição tanto do produto como dos
processos para obtê-lo, bem como das tarefas administrativas e gerenciais necessárias. Pode
ser apresentada de duas maneiras:
•
Sob a forma de um organograma, também conhecida como árvore de
decomposição do projeto; ou
•
Como uma relação ou tabela.
As duas formas são equivalentes e, em geral, são usadas simultaneamente num
mesmo projeto.
A Figura 2 exibe um exemplo do que seria parte da WBS de um projeto de
desenvolvimento de uma aeronave. As linhas tracejadas indicam a existência de mais
elementos e mais níveis nessa WBS.
O estudo de caso, apresentado no Capítulo V, utiliza a WBS de projetos como base
para os experimentos realizados neste trabalho.
Maiores detalhes sobre WBS podem ser obtidos em (PMI, 2001) que, além de
tratar especificamente deste assunto, apresenta uma série de exemplos referentes a tipos de
projetos distintos. Outra fonte que pode ser consultada é Flemming e Koppelman (2000).
12
Figura 2 : Exemplo de Estrutura Analítica de Projeto
2.1.5
Relato do Desempenho de Projetos
A técnica Análise de Valor Agregado (Earned Value Analysis), é uma das
principais ferramentas da gerência de projetos, utilizadas pelo gerente, para se determinar o
desempenho de um determinado projeto. O conceito da análise de valor agregado foca-se na
análise do custo real frente ao esperado para o trabalho efetivamente realizado. Por meio dela
pode-se apurar se o projeto está dentro ou fora do orçamento e cronograma previstos.
Em resumo, a técnica consta de um pequeno conjunto de variáveis, obtidas do
planejamento (linha de base) e controle do projeto (valores de controle, obtidos
periodicamente), e da realização de algumas operações matemáticas básicas realizadas sobre
essas variáveis, permitindo a confecção de relatórios de desempenho.
O estabelecimento da linha de base do projeto na fase de planejamento é essencial, e a
Figura 3 ilustra os passos necessários para obtê-la. Nota-se que, em primeira instância, devese definir o trabalho a ser realizado elaborando-se a WBS, num segundo passo agendam-se as
atividades, alocam-se os recursos necessários, e por fim, constitui-se a referência para o
13
projeto por meio da soma dos custos orçados para as atividades. Tem-se então, a linha de base
para acompanhamento do projeto em termos de custo e prazo.
Figura 3: Estabelecimento da Linha de Base do Projeto.
Segundo Flemming e Koppelman (2000), o PMI define a linha de base de um
projeto, em inglês PMB (Performance Measurement Baseline), como sendo a soma de vários
CAPs (Control Account Plans), que são um conjunto de informações atribuídas a
determinados elementos da WBS, servindo de ponto de controle e gerenciamento. A PMB é a
referência para a Análise de Valor Agregado.
Cada CAP deve conter, pelo menos, os seguintes elementos discretos:
•
Um escopo específico para o trabalho (breve descrição do escopo);
•
Um espaço de tempo para execução (datas de início e fim para cada
atividade); e
•
Um orçamento aprovado para o trabalho (expresso em valor monetário,
horas ou unidades).
Alguns atributos adicionais podem ser definidos, como por exemplo, os seguintes:
•
Nome da pessoa responsável pelo CAP, ou seja, o Control Account
Manager;
14
•
Responsável pelo departamento;
•
Tipo do esforço: não recorrente ou recorrente;
•
Divisão de pacotes de trabalho discretos (Discrete Work Packages); e
•
Método utilizado para mensurar o desempenho. Por exemplo, fórmula e
percentual de completeza.
A técnica Análise de Valor Agregado se baseia num conjunto de variáveis. Destas
variáveis, 3 (três) são consideradas básicas e representam as entradas que devem ser
fornecidas pela equipe de gerenciamento em determinadas datas do projeto, propiciando a
execução da análise:
•
PV (Planned Value) é o custo orçado para o trabalho planejado que
indica o valor referente à parcela do orçamento que deveria ser gasto,
considerando o custo de linha de base;
•
EV (Earned Value) é o valor agregado. Flemming e Koppelmam (2000)
apresentam 8 (oito) métodos a partir dos quais pode-se obter o valor
agregado, um deles, por exemplo, consiste em estimar o percentual do
trabalho realizado até a data de controle e multiplicá-lo pelo valor
planejado para esta mesma data; e
•
AC (Actual Cost) mostra o custo real incidente para o trabalho já
realizado por um recurso para uma atividade, até a data de controle do
projeto.
Os valores de PV, EV e AC são acumulados ao longo do tempo.
Um par de variáveis é calculado a partir dos valores das variáveis básicas,
propiciando a análise de variações. São elas:
•
SV (Schedule Variance) é a diferença, em termos de custo, entre o valor
agregado (EV) e o valor planejado (PV). Se SV for positiva, o projeto está
adiantado, em termos de custo, caso contrário, está atrasado; e
•
CV (Cost Variance) é a diferença entre o valor agregado (EV) e o custo
real (AC), até a data de controle do projeto. Se CV for positiva, o custo
está aquém do valor planejado, caso contrário, o custo do projeto
ultrapassa o orçamento.
15
A técnica Análise de Valor Agregado propicia o monitoramento de índices de
desempenho do projeto ao longo do tempo. Com base nas variações citadas anteriormente,
pode-se obter os índices de desempenho para os valores do projeto na data de controle em
questão, a saber:
•
SPI (Schedule Performance Index) é a divisão entre o valor agregado
(EV) e o valor planejado na linha de base (PV). Se SPI for menor que 1
indica que o projeto está sendo realizado com um progresso menor que o
planejado; e
•
CPI (Cost Performance Index) é a divisão entre o valor agregado (EV) e
o custo real do projeto (AC) até a data de controle. Se CPI for menor que
1, indica que o projeto está custando mais do que o previsto.
O gráfico da Figura 4, obtido e adaptado a partir de Flemming e Koppelman
(2000), ilustra as interpretações possíveis para os valores das variáveis SPI e CPI.
Datas de Controle
+
Bom e melhorando
1.00
De acordo com o plano
Ruim e piorando
-
Tempo
Figura 4: Monitoramento de Índices de Desempenho
Olhando para a Figura 4 percebe-se que se uma variável de índice de desempenho
apresentar um valor superior a 1.00, indica um resultado positivo, além do esperado para o
projeto. Se for exatamente 1.00 indica que o andamento do projeto está ocorrendo conforme o
programado, e se for inferior a 1.00 indica um resultado negativo, aquém do esperado para o
projeto.
16
A partir dos elementos descritos até então, é possível realizar previsões para o
projeto com base em informações referentes à data de controle, extraindo informações como
as seguintes:
•
BAC (Budget At Completion) é orçamento total para o projeto com base
no que foi planejado (PV), podendo ser revisado no decorrer do
gerenciamento;
•
WR (Work Remaining) é o valor orçado para o trabalho ainda não
realizado na data de controle;
•
EAC (Estimates Costs at Completion) é o valor financeiro que
representa o custo final estimado para o projeto, quando concluído. É
obtido a partir dos custos reais incorridos (AC), dos fundos restantes
estimados (WR) e de um fator de desempenho (fd) específico.
•
FR (Funds Remaining) é a diferença entre o valor orçado para o término
do projeto (que pode ser o original, BAC, ou um novo valor negociado que
pode ser o EAC) e o custo real do projeto até a data de controle (AC); e
•
TCPI (To Complete Performance Index) é usado para determinar o
fator de desempenho, que se deve ter em termos de custo, para se
completar o trabalho restante, a partir da última data de controle do
projeto.
A Tabela 2 apresenta as variáveis comentadas anteriormente, cujos valores são
obtidos de forma direta ou calculada e na Figura 5 apresenta-se um gráfico mostrando as
principais variáveis da Análise de Valor Agregado. Várias inferências adicionais podem ser
feitas com base nos valores das variáveis apresentadas anteriormente, permitindo a realização
de diversas análises sobre o desempenho do projeto.
A técnica Análise de Valor Agregado pode ser aplicada num determinado
elemento da WBS e, por meio de consolidações, pode-se obter os resultados para o projeto
como um todo.
17
Tabela 2: Variáveis da Análise de Valor Agregado.
Variável
PV
EV
Descrição
Forma de Obtenção
“Planned Value”
Direto do Planejamento do Projeto
Valor Planejado
“Earned Value”
Direto do Acompanhamento do
Valor Agregado
Projeto, com base no trabalho
realizado
“Actual Cost”
AC
Custo Real
“Schedule Variance”
SV
Índice de Desempenho da Programação
“Cost Performance Index”
CPI
Índice de desempenho do custo
“Budget At Completion”
BAC
Orçamento para Conclusão
“Work Remaining”
WR
CV = EV – AC
Variação do Custo
“Schedule Performance Index”
SPI
SV = EV – PV
Variação da Programação
“Cost Variance”
CV
Direto Depto./Sistema Financeiro
SPI =
EV
PV
CPI =
EV
AC
BAC = ∑ PV
WR = BAC – EV
Trabalho Restante
“Estimate At Completion”
EAC
Custo Estimado para Conclusão
Alternativas de fatores de desempenho:
1) – “Mathematical” onde fd = 1;
2) – “Low End Cumulative CPI EAC” onde
fd = CPI (acumulado); e
EAC = AC +
WR
fd
3) – “High End Cumulative CPI times SPI EAC”
onde fd = CPI X SPI (acumulados).
Obs: Segundo Flemming e Koppelman (2000) a
alternativa 2 é a mais utilizada.
“Funds Remaining”
FR
Fundos Restantes
“To Complete Performance Index”
TCPI
FR = (BAC ou EAC) – AC
Índice de desempenho exigido para conclusão
TCPI =
WR
FR
18
Figura 5: Gráfico com Elementos da Análise de Valor Agregado.
Para ilustrar a aplicação da técnica Análise de Valor Agregado, bem como explicar
o gráfico da Figura 5, suponha o seguinte exemplo: no projeto da Aeronave XYZ, da Figura 2,
foi realizado um planejamento no qual foi programado o desenvolvimento do motor num
prazo total de 10 meses e orçados em 100.000 unidades monetárias, que chamaremos de
“umos”. Suponha que os custos planejados mensais são constantes e iguais a 10.000 umos e
os relatos de desempenho ocorrem mensalmente.
Ao final do primeiro mês, observou-se que apenas 80% (oitenta por cento) do
trabalho planejado foi realizado. A equipe funcional, responsável pelo gerenciamento
financeiro da organização, comunicou ao gerente do projeto que os gastos reais no primeiro
mês em relação ao projeto e concepção do motor foram de 11.000 umos. Tem-se então, os
19
valores das três variáveis básicas (PV, EV e AC) para a data de controle referente ao primeiro
mês do projeto e concepção do motor:
•
PV = 10.000 umos
•
EV = 80% de PV = 8.000 umos
•
AC = 11.000 umos
De posse das variáveis básicas pode-se aplicar as fórmulas da técnica para realizar
a análise. Sendo assim, calcula-se as variações (CV e SV) e os índices de desempenho (CPI e
SPI):
•
CV = EV – AC = 8.000 – 11.000 = -3.000 umos
•
SV = EV – PV = 8.000 – 10.000 = -2.000 umos
•
CPI =
•
EV
8.000
SPI = SV =
= 0,80
10.000
EV
8.000
=
= 0,72
AC
11.000
Observando o resultado dos cálculos anteriores, como os valores de CV e SV são
negativos, chega-se à conclusão que, na data de controle referente ao primeiro mês, o projeto
está atrasado e consumindo mais recursos do que o esperado. Confirmando isso, nota-se que
as variáveis de índice de desempenho possuem valores menores que 1.
O BAC (orçamento para a conclusão) é obtido diretamente, pois está se analisando
apenas um elemento da WBS. Se fosse feita a análise do projeto como um todo seria
necessário realizar consolidações e analisá-las. O BAC está relatado no enunciado e possui o
valor de 100.000 umos.
O trabalho restante (WR), ou seja, o valor orçado para o trabalho ainda não
realizado, é o seguinte:
•
WR = BAC – EV = 100.000 – 8.000 = 92.000 umos
O custo estimado para conclusão do projeto e concepção do motor pode ser
calculado com base em três técnicas, como citado anteriormente:
•
“Mathematical EAC” = AC +
WR
= 11.000 + 92.000 = 103.000 umos
1
20
•
“Low End Cumulative CPI EAC” =
AC +
•
92.000
WR
= 11.000 +
= 138.777 umos
CPI (acumulado)
0,72
“High End Cumulative CPI times SPI EAC” =
AC +
92.000
WR
= 11.000 +
=
CPI (acumulado) xSPI (acumulado)
0,576
170.722 umos
Os fundos restantes (FR) podem ser obtidos a partir de qualquer um dos
orçamentos para conclusão, BAC ou EAC, subtraindo o custo real do projeto (AC) até a data
de controle:
•
FR = BAC – AC = 100.000 – 11.000 = 89.000 umos; ou
•
FR = EAC – AC = 138.777 – 11.000 = 127.777 umos (utilizando a
técnica “Low End Cumaltive CPI EAC”).
Finalmente, pode-se calcular o índice de desempenho exigido para a conclusão do
projeto e concepção do motor:
•
TCPI =
WR
92.000
=
= 1,03 (com FR a partir do BAC); ou
89.000
FR
•
TCPI =
WR
92.000
=
= 0,72 (com FR a partir do EAC).
FR 127.777
O TCPI obtido com FR a partir do BAC indica que o projeto precisa ter um SPI de
1,03 nos nove meses restantes enquanto que se houver aporte adicional de 27.777 umos
(conforme o obtido com FR a partir do EAC), pode-se manter o SPI pobre de 0,72.
A técnica Análise de Valor Agregado envolvendo projetos relacionados, foi o tema
selecionado para o desenvolvimento do estudo de caso apresentado no Capítulo V. Nele um
determinado projeto de uma empresa pode ser associado ao elemento da WBS de um projeto
21
maior, liderado por uma empresa parceira, e os relatos de desempenho, registrados para esse
projeto menor, refletem no relato de desempenho do projeto da empresa líder.
2.2 Projetos de Larga Escala Envolvendo Empresas
Parceiras e Contratadas
Em Projetos de Larga Escala - PLE (Large-Scale Projects – LSP) geralmente
existe um grande número de envolvidos e interessados (stakeholders), tais como: parceiras,
patrocinadores, contratantes, contratadas, consultores e fornecedores. Em geral, empresas
parceiras e contratadas são todas parte de um esforço único no qual cada uma é responsável
pelo desenvolvimento e produção de um dado subsistema, subproduto ou componente que se
integra aos demais, no sentido de se obter o produto do projeto como um todo.
PLEs geralmente são projetos com duração superior a 12 (doze) meses, envolvem
milhares de participantes e possuem um orçamento na ordem de dezenas de milhões de
dólares. Exemplos desse tipo de projeto incluem missões espaciais, aeronaves, e automóveis.
O envolvimento de várias empresas causa dependências em termos de informação e
sincronização, e essas dependências eventualmente podem afetar o prazo, o custo e o escopo
do projeto.
Dois tipos de relacionamentos entre as empresas participantes de PLEs são
observados, a saber, contratação e parceira. Para caracterizar e diferenciar esses
relacionamentos, considere o exemplo de um projeto de produto composto de componentes,
realizado por várias empresas. No relacionamento de contratação, geralmente a empresa líder
do projeto especifica o componente que é fabricado pela empresa contratada. Existe um
contrato que rege as obrigações de fornecedor pela contratada e as obrigações de solicitante
pela empresa proprietária, ou lider, do projeto. Já no relacionamento de parceria, a empresa
parceira não apenas fabrica o componente como participa ativamente do seu design, ou seja, a
empresa líder do projeto delega grande parte do design do componente à empresa parceira.
Neste caso, relacionamento é mais próximo, e de certa forma, ocorre uma interação maior
entre as empresas.
A utilização de parcerias e contratações em projetos é vista pelas empresas líderes
de projetos como uma forma de se dividir os riscos, reduzir custos de engenharia e produção,
bem como reduzir o tempo de lançamento do produto no mercado (time-to-market). No caso
das empresas parceiras das líderes de projetos, o interesse pela participação nestes, se dá
22
principalmente pelo fato de que elas passam a ter participação nas vendas do produto que está
sendo concebido.
Os projetos de larga escala geralmente contemplam os dois relacionamentos ao
mesmo tempo. Um exemplo ilustrativo é apresentado na Figura 6, que na seqüência, é
devidamente comentada.
C1.1
P2.1
P2
C1
P1.1
E
C2.1
C2
P1
Figura 6: Relacionamento entre Empresas Parceiras e Contratadas.
Suponha uma empresa (E) que representa, por exemplo,
uma montadora de
aeronaves que possui um projeto de lançamento, construção e produção de um novo modelo
de aeronave. Para tanto, ela pode contar com empresas parceiras (P) e contratadas (C) que
desenvolvem componentes que se integram a esse novo modelo. Neste cenário, a empresa (E)
divide os riscos de projeto, produção e, conseqüentemente, os lucros referentes às futuras
vendas do produto, com as parceiras (P1), (P2), e indiretamente, com a empresa (P2.1). Por
outro lado, ela contrata os serviços das empresas (C1) e (C2) para o desenvolvimento de
outros componentes. Observando a posição da contratada (C1), suponha que um contrato de
fornecimento foi firmado com ela. Esta por sua vez divide a responsabilidade com a empresa
(P1.1), sua parceira, e contrata os serviços de uma outra empresa (C1.1) para atender à
encomenda.
Nota-se que o projeto da empresa (E) está na dependência de outros projetos que
são da responsabilidade de terceiros. Os projetos das empresas situadas nas extremidades da
rede podem influenciar o cronograma e o custo do projeto da empresa (E). O mesmo ocorre
com a contratada (C1) que desenvolve parte do produto e depende de outras duas empresas
(C1.1 e P1.1) para atender seu cliente (E).
Em projetos desse tipo, algumas áreas de conhecimento da gestão de projetos
definidas pelo PMBOK (PMI, 2000) são evidenciadas, uma vez que este tipo de projeto
23
geralmente transpõe as barreiras da organização. Nesse caso destacam-se os processos
relativos à Gestão de Riscos, Gestão de Aquisições, Gestão de Integração e Gestão da
Comunicação.
2.3 Um exemplo de Projeto de Larga Escala Envolvendo
Empresas Parceiras
A Empresa Brasileira de Aeronáutica S.A. – EMBRAER, segundo informações
constantes em (EMBRAER, 2002b), atualmente é a quarta maior fabricante de aeronaves
comerciais do mundo. Posição alcançada graças a excelência de seus produtos e à tecnologia
de ponta utilizada por ela no segmento aeronáutico. Fundada em 1969, ela possui mais de 30
anos de experiência em projeto, fabricação, comercialização e pós-venda, e até 2002, já
entregou cerca de 5.500 aviões, que estão em operação nos diversos pontos do globo terrestre.
Ela possui uma base global de clientes e importantes parceiros de renome mundial, o que
resulta numa significativa participação no mercado.
A variedade de modelos de aeronaves para aplicações distintas, proposto por ela
atualmente, faz com que vários programas, envolvendo vários projetos, sejam desenvolvidos
ao mesmo tempo.
O grande número de componentes a serem projetados, desenvolvidos e integrados
num modelo de aeronave, caracteriza os projetos da EMBRAER como Projetos de Larga
Escala.
Atualmente a EMBRAER conduz, dentre outros, o programa denominado
EMBRAER-170/190 que envolve projetos de engenharia para o lançamento de quatro
modelos de aeronaves. Para o desenvolvimento desse programa, ela conta com a participação
de vários parceiros, contratados e fornecedores espalhados pelo mundo. Alguns dos principais
parceiros são: a Kawasaki (Japão) - responsável por segmentos estruturais; a Hamilton
Sundstrand (EUA) – responsável por parte de sistemas; a Honeywell (EUA) – responsável por
parte de sistemas; a Parker Hannifin (EUA) – responsável por parte de sistemas; a C&D
Aerospace (EUA) – responsável pelos interiores; a General Electric (EUA) – responsável
pelos motores; e outras como a Sonaca (Bélgica), a Latécoère (França) e a Gamesa (Espanha).
Como pode ser observado, cada um deles é responsável pelo projeto e elaboração de um ou
mais componentes que se integram a esses modelos conforme os requisitos especificados pela
24
EMBRAER. A Figura 7 (EMBRAER, 2002), ilustra a divisão de responsabilidades desse
projeto, bem como os principais parceiros envolvidos.
Figura 7: EMBRAER 170/190 - Parceiros do Programa.
O relacionamento com os parceiros é de certa forma, muito próximo, apesar da
distância geográfica que os separa. Nesses casos, quando há a necessidade de uma interação
mais intensa, equipes de técnicos e engenheiros dos parceiros se deslocam para as instalações
da EMBRAER, para desenvolver atividades de projeto e especificação dos componentes que
lhes foram atribuídos, visando facilitar a integração deste componente ao produto do projeto.
A comunicação de informações de projeto entre a EMBRAER e seus parceiros é realizada por
meio de um portal, acessível a partir de uma rede privada denominada “Sita Network”. Esse
portal disponibiliza formulários e armazena essas informações num repositório central situado
na sede da EMBRAER, permitindo o acompanhamento e o controle do andamento dos
projetos dos diversos componentes que se integram ao modelo de aeronave que está sendo
desenvolvido.
A Figura 8 (EMBRAER, 2002) ilustra a “Sita Network” e os principais pontos
espalhados pelo mundo, que acessam o referido portal.
25
Figura 8: EMBRAER 170/190 - Intranet para Comunicação com Parceiros do Programa.
O Programa EMBRAER-170/190 conta com equipes responsáveis pela gestão dos
projetos e com equipes funcionais, alocadas a cada um deles. Estas equipes compõem
escritórios de gestão de programas (Program Management Offices), e como um programa é
constituído de projetos, é definido então, um escritório para o gerenciamento de cada projeto
(Project Management Office).
Tratando-se de escritórios de gestão projetos, Kerzner (1997) aponta as seguintes
responsabilidades para um:
•
Atuar como o ponto focal para a obtenção de informações a respeito do
projeto, seja por membros internos ou externos à organização;
•
Controlar prazos, custos e desempenho visando atender a requisitos de
contratos;
•
Garantir que todo o trabalho requerido é documentado e distribuído às
pessoas chave; e
•
Garantir que todo o trabalho executado está autorizado e fundamentado por
documentações contratuais.
A maior responsabilidade do gerente do projeto e do pessoal do escritório de
gestão do projeto é a integração do trabalho por meio das linhas funcionais da organização.
Unidades funcionais como engenharia, pesquisa e desenvolvimento, e manufatura, junto com
parceiros e contratados, devem seguir as mesmas especificações, desenhos e objetivos. Sendo
26
assim, existem, nas dependências da EMBRAER, equipes de projeto e engenharia das
empresas parceiras atuando .
Das responsabilidades dos escritórios de gestão de projetos apresentadas, derivam
as quatro maiores atividades desempenhadas por eles, que necessitam de pessoal devidamente
treinado e capacitado para a sua execução. São elas:
•
Integração de atividades funcionais e do projeto;
•
Comunicação interna e externa;
•
Planejamento e controle de riscos e incertezas; e
•
Controle efetivo do Projeto.
A Figura 9, construída com base em Kerzner (1997), ilustra as definições
apresentadas. Nota-se que ela exibe o gerente do projeto, e seus assistentes como integrantes
do escritório de gestão do projeto. Esses assistentes representam o restante dos profissionais
que atuam nesse escritório. Da integração de atividades funcionais e do projeto, decorre a
participação de gerentes e equipes funcionais da organização, que junto com o pessoal do
escritório de gestão do projeto compõem o time do projeto.
Assistentes do
Gerente do Projeto
Gerentes
Funcionais
Gerente do Projeto
Equipes
Funcionais
Escritório de Gestão
do Projeto
Time do Projeto
Figura 9: Escritório do Projeto e Time do Projeto.
Maiores detalhes sobre escritórios de gestão de projetos e programas podem ser
obtidos em Kerzner (1997) e Nicholas (1990).
27
2.4 Ferramentas Computacionais de Apoio à Gestão de
Projetos
Segundo Kerzner (1997), o gerenciamento eficiente de um projeto requer mais do
que um bom planejamento, ele requer que informações relevantes sejam obtidas, analisadas e
revistas em tempo hábil. Com isso, problemas podem ser previstos, identificados e analisados
antecipadamente, assim como o impacto de alterações feitas no planejamento de atividades do
projeto.
Tais necessidades demandam a utilização de ferramentas computacionais que
auxiliam o processo de desenvolvimento de projetos, ajudando os profissionais, por exemplo,
no planejamento e controle de atividades e custos do projeto, na especificação e gerência de
requisitos, no controle de versões de documentos e deliverables, na análise do impacto de
alterações, no suporte à comunicação e ao trabalho cooperativo e, na obtenção de informações
sobre os custos reais do projeto. Essas ferramentas podem ser agrupadas nas seguintes
categorias:

Ferramentas destinadas à especificação, análise e gerência de requisitos;

Ferramentas para auxílio ao planejamento e controle de projetos –
Softwares de Gestão de Projetos - SGP;

Ferramentas de apoio à comunicação e ao trabalho cooperativo;

Ferramentas para controle de versões e alteração de configuração
(Version Control Management and Change Configuration Management);
e

Ferramentas de apoio à gestão empresarial (Enterprise Resource
Planning – ERP).
O universo coberto por essas ferramentas é consideravelmente amplo, daí talvez, o
motivo pelo qual a integração entre elas ainda é, de certa forma, fraca e em muitos casos
inexistente. Um possível motivo disto talvez seja o fato das empresas fornecedoras desses
aplicativos possuírem focos distintos, nos quais uma é especialista em SGP, a outra em
softwares de gerência de requisitos, e assim por diante.
Nas subseção a seguir apresenta-se um detalhamento sucinto das categorias de
ferramentas computacionais citadas anteriormente.
28
2.4.1
Ferramentas de Apoio à Especificação, Análise e
Controle de Requisitos
A satisfação dos requisitos, sem dúvida é uma das chaves para o sucesso de um
projeto. Os requisitos representam as expectativas e necessidades do cliente em relação a um
produto ou serviço, ou seja, o que o produto/serviço e seus componentes devem ter/fazer para
satisfazê-las. Diante disso, há a necessidade de se captar e comunicar os requisitos a todos os
envolvidos no respectivo projeto. E uma das formas para garantir o sucesso do
empreendimento, é que os documentos de requisitos devem controlar o processo de
desenvolvimento do projeto, sendo também utilizados para se verificar e validar os resultados
parciais e finais.
Nota-se então, a importância da gestão de requisitos no desenvolvimento de
projetos, uma vez que eles são peças-chave na definição do escopo, produtos e subprodutos de
um projeto. Philip Crosby (LIVEWARE, 2001) define “qualidade” como sendo a
conformidade com os requisitos, ou seja, atendendo aos requisitos, automaticamente, garantese a qualidade do produto ou serviço proposto ao cliente.
Para a Telelogic (2001), um “bom” requisito possui características como:
corretude, completeza, consistência, ausência de ambigüidade, possibilidade de ser verificado
(testado), e possibilidade de ser acompanhado. Tais características tornam a gestão de
requisitos uma tarefa árdua no sentido de se verificar e validar todas elas para o conjunto de
requisitos de projetos.
O uso de ferramentas computacionais de apoio à gestão de requisitos pode aliviar
essa carga dos profissionais envolvidos nesse processo. Wiegers (WIEGERS,1999) analisa
algumas dessas ferramentas e apresenta os principais motivos para se fazer uso das mesmas:
•
Controle de versões e alterações – Os requisitos de um projeto podem,
e geralmente, sofrem alterações no decorrer de seu desenvolvimento. As
ferramentas de auxílio à gestão de requisitos apresentam recursos de
armazenamento de históricos de alterações e versões anteriores dos
documentos de requisitos que podem ser recuperados com facilidade.
•
Registro de atributos dos requisitos – Este recurso possibilita a
atribuição de informações a respeito de um requisito como: identificador
único, responsável, prioridade, custo, dificuldade, estabilidade, risco e
número de versão.
29
•
Ligações entre requisitos e outros elementos - Este recurso permite
estabelecer a “rastreabilidade” de requisitos, permitindo conhecer a origem
e o impacto de um determinado requisito num produto ou solução.
•
Acompanhamento de status - Tal recurso fornece respostas aos gerentes
de projetos sobre o percentual de atendimento dos requisitos até a data
atual.
•
Visualização de subconjuntos de requisitos – Podem ser realizadas
ordenações, filtragens ou consultas ao banco de dados para visualizar
subconjuntos de requisitos com base nos valores de seus atributos.
•
Controle de acesso – Conjuntos de permissões de acessos podem ser
configuradas e atribuídas a grupos ou a usuários individuais. Acessos
podem ser feitos por meio da Internet permitindo o compartilhamento de
informações de requisitos a todos os membros da equipe do projeto,
mesmo que estes estejam geograficamente distantes.
•
Comunicação com stakeholders – Alguns recursos de comunicação
provêm mecanismos para a discussão entre os membros da equipe e envio
de mensagens eletrônicas.
Além desses recursos pode-se destacar também, a capacidade de integração com
outras ferramentas como, por exemplo, editores de texto, softwares de gestão de projetos e
ferramentas de modelagem visual de sistemas. Pode-se citar como exemplos dessas
ferramentas, softwares como: Telelogic DOORS/ERS, Rational Requisite Pro e Caliber-RM.
2.4.2
Ferramentas de Apoio ao Planejamento e
Monitoramento de Projetos
Planejar, acompanhar e controlar projetos exige a utilização de uma série de
técnicas e ferramentas. Tal necessidade deu origem a um nicho de mercado de software que
atualmente oferece um grande conjunto de ferramentas computacionais destinadas ao auxílio
dos gerentes na difícil tarefa de planejamento, acompanhamento e controle de projetos.
Algumas características e recursos desses softwares são apresentados por Kerzner
(1997) e se aplicam à maioria dos pacotes de software de gestão de projetos – SGP. São elas:
30
•
Planejamento, acompanhamento e monitoramento de atividades,
recursos e custos. A formatação dos dados, para descrição do projeto no
sistema, geralmente é baseado em topologias de rede padrão como
Critical Path Method – CPM, Program Evaluation and Review
Technique – PERT, ou Precedence Diagram Method – PDM. Os
elementos da WBS são catalogados com suas datas estimadas de início
e término, os recursos associados a eles, e dados referentes ao seu custo
atual, podendo a qualquer momento ser atualizado, propiciando o
acompanhamento do progresso do projeto a partir de vários tipos de
consultas e relatórios, atendendo às especificações e requisitos de
ferramentas e técnicas expostas pelo PMBOK (PMI, 2000) nas diversas
áreas da gestão de projetos, principalmente às áreas de gestão e prazo e
custos.
•
Relatórios diversos, tanto textuais como gráficos, podem ser gerados
e customizados complementando as funcionalidades expostas no item
anterior. Como exemplos de relatórios possíveis, pode-se destacar os
seguintes:
o Relatório de custos orçados para o trabalho planejado (Planned
Value - PV);
o Relatório de custos orçados para o trabalho executado (Earned
Value - EV);
o Relatório de comparação entre gastos planejados e reais;
o Análise de Valor Agregado (Earned Value Analysis);
o Índices de desempenho de programação e custos;
o Relatórios de fluxo de caixa;
o Análise de Caminho Crítico; e
o Relatórios baseados em padrões governamentais (DoD, DoE,
NASA), formatados para sistemas de monitoramento de
desempenho (Performance Monitoring Systems – PMS).
•
Calendário do Projeto, que possibilita ao usuário estabelecer, por
exemplo, trabalhos semanais baseados em dias de trabalho reais. Dessa
forma, pode especificar períodos de folga, não aplicáveis ao
31
desenvolvimento das atividades, como: finais de semana, feriados e
períodos de férias.
•
Análise What-if, que permite ao usuário alterar dados do projeto em
bases de dados duplicadas e executar análises comparativas, tabulares
ou gráficas, de forma simplificada, entre o que foi efetivamente
planejado e o que se está simulando.
•
Análise Multiprojetos, que é uma característica de softwares de gestão
de projeto mais sofisticados, que oferecem uma estrutura de banco de
dados que possibilita a análise e geração de relatórios cruzando
informações de projetos. Custos e módulos de programação são
compartilhados em bases de dados comuns aos projetos permitindo
integração entre eles e minimizando problemas de inconsistência e
redundância de dados.
Kerzner (1997) apresenta também, que a maioria dos SGPs oferecem recursos
extensíveis para o monitoramento e controle de projetos, incluindo o seguinte:
•
Capacidade do sistema no suporte ao número de atividades e sub-redes;
•
Esquemas de rede que envolvem diagramas de atividade e precedência
de relacionamento;
•
Calendários de datas com diversas variações e opções de algoritmos;
•
Gráficos de Gantt ou de barras em escalas de tempo customizáveis;
•
Gerador de relatórios flexível;
•
Atualizações automáticas do projeto como um todo, em virtude de
alterações;
•
Controle de Custos incluindo planejamento e acompanhamento;
•
Datas programadas para início e término de atividades. Os cálculos
utilizam essas datas como regras;
•
Ordenação da lista de atividades conforme especificado pelo usuário;
•
Alocação de recursos de forma opcional utilizando algoritmos
heurísticos;
•
Possibilidade de plotagem dos diagramas de rede; e
•
Exigência mínima de memória de hardware para a execução do
software.
32
O advento da Internet aliado à necessidade de comunicação entre as equipes do
projeto fez com que os fabricantes dessas ferramentas disponibilizassem recursos que
possibilitam, por exemplo, o seguinte:
•
A geração de relatórios que podem ser publicados na Internet;
•
O acesso remoto a repositórios de informações do projeto por meio da
Internet;
•
A manutenção de informações do projeto por meio de interfaces
implementadas para execução em navegadores Web; e
•
O envio automático de mensagens eletrônicas a membros específicos
da equipe de projetos.
São exemplos dessas ferramentas, os seguintes softwares: Primavera, Microsoft
Project e Project Server.
2.4.3
Ferramentas de Apoio à Comunicação e ao
Trabalho Cooperativo
As equipes e demais stakeholders de projetos nem sempre se encontram
geograficamente próximos. Dependendo do tamanho a empresa, mesmo que o projeto não
ultrapasse suas barreiras, existem dificuldades que norteiam a comunicação e o trabalho em
grupo. Nicholas (1990), afirma que o sucesso do projeto é caracterizado pela boa
comunicação e alta qualidade das informações compartilhadas e trocadas. Durante o
desenvolvimento de um projeto ocorrem várias reuniões para revisão e intercâmbio de
informações e instruções sobre os objetivos do projeto, status e alterações. Quando o projeto
envolve equipes grandes e que estejam geograficamente distribuídos, a realização dessas
reuniões é dispendiosa e representa elevados custos para o projeto.
Os ambientes de trabalho cooperativo informatizado, conhecidos como sistemas de
groupware, oferecem recursos que agilizam o processo de comunicação de projetos,
viabilizando o trabalho cooperativo à distância, no qual documentos eletrônicos podem ser
intercambiados, reuniões e conferências eletrônicas podem ser realizadas.
Yano (1998), citando Ellis, define groupware como sistemas baseados em
computadores que suportam grupos de pessoas engajadas numa tarefa ou objetivo comum e
provêem uma interface para um ambiente compartilhado.
33
Os usuários desses sistemas podem interagir de duas formas:
•
Síncrona, na qual existe uma noção de simultaneidade no tempo, pois
os eventos gerados por um usuário são imediatamente notificados para
outros usuários; e
•
Assíncrona, cuja interação ocorre por meio de recipientes de eventos.
Aqui, os eventos são introduzidos num recipiente, e estes somente são
notificados a outros usuários se esses fizerem um acesso ao recipiente.
Com relação à localização espacial dos usuários classificam-se as aplicações em
remotas ou locais. A diferença básica é que nas aplicações locais ocorre, além da interação
por meio do sistema, a interação face a face.
A partir de Yano (1998) pode-se montar a Tabela 3 que exibe exemplos de tipos de
groupware e também algumas de suas características.
Tabela 3: Exemplos de Groupware.
Sistema
Modo de
Interação
Mensagens
Assíncrono
Localização
espacial dos
usuários
Local/Remoto
Exemplo específico
ou aplicação
Conferências
Assíncrono
Local/Remoto
Lista de discussão informatizada
Síncrono
Remoto
Sistemas de geração de idéias cujas
Sistemas de envio automático de E-mail
por computador
Conferência em
tempo real
mensagens apresentadas precisam
imediatamente ser exibidas a todos os
membros
Co-autoria
Assíncrono
Local/Remoto
Suporta a cooperação entre co-autores
de um documento em produção
Argumentação
Assíncrono
Local/Remoto
Suporta o desenvolvimento estruturado
de negociações e argumentações entre
vários participantes
Salas de reunião
eletrônica
Síncrono
Local
Suporte a sistemas de tomadas de
decisão em grupo. Ex. CoLab da
XeroxParc
34
Os exemplos de sistemas contidos na Tabela 3, nem sempre se resumem a
soluções de software apenas. No caso das salas de reunião eletrônica, equipamentos de vídeo
e som específicos são utilizados.
Algumas soluções de pacotes de software que podem ser citados como exemplos
de groupware são os seguintes: Lotus Notes, ICQ e Microsoft NetMeeting.
Algumas empresas desenvolvem suas próprias soluções, como por exemplo, a
EMBRAER (Empresa Brasileira de Aeronáutica S.A.), que desenvolveu um portal contendo
diversas ferramentas que possibilitam o trabalho cooperativo com seus parceiros de projetos.
Maiores detalhes sobre esse portal são fornecidos na Seção 2.3.
Como pode ser visto, ferramentas para trabalho cooperativo podem ser utilizadas
tanto na gestão como no design de projetos .
2.4.4
Ferramentas de Apoio à Gestão Empresarial
A importância dessas ferramentas para o processo de gestão de projetos está
relacionada ao fato de que elas podem ser fortes aliadas dos gerentes na obtenção de
informações referentes, principalmente, aos custos realizados no projeto até uma determinada
data. Essa categoria de software, também conhecida como ERP (Enterprise Resource
Planning), implementa funcionalidades que visam auxiliar empresas na execução de suas
tarefas diárias, como por exemplo: vendas, estoque, faturamento, contas a pagar e a receber,
contabilidade e controle bancário.
Esses sistemas, em geral, são caros e exigem grandes mudanças na empresa. A
plataforma de negócio é largamente afetada pois os requisitos em termos de processamento e
armazenamento aumentam de forma considerável.
Esses sistemas em geral são
parametrizados (configurados) para uma empresa específica. Além disso, para operacionalizar
as transações e garantir sua consistência, uma grande quantidade de dados é demandada. Isso
acarreta em uma explosão de necessidade em termos de tabelas utilizadas para essas
configurações e realização de transações.
Esses sistemas tentam eliminar os chamados “feudos departamentais” e substituir
por uma visão mais integrada, única e racional da empresa. Para isso, uma instalação e uma
plataforma técnica servindo todos os processos e níveis são requeridos. Ilhas de
automatização são conectadas em sistemas de alcance geral que servem todas as funções.
35
Existe uma única cultura, focada no desempenho de negócio, medido nos padrões de
desempenho como retorno sobre o patrimônio, preço de estoque, crescimento e fatia de
mercado. Essa cultura dá origem a uma nova linhagem de software: business intelligence.
No tocante à gestão de projetos, dados podem ser obtidos dos módulos financeiros,
mais especificamente, o de contas a pagar e contabilidade, e serem registrados nos sistemas de
gestão de projetos visando o levantamento dos custos reais do projeto.
Laudon (2000) apresenta maiores informações a respeitos dessas ferramentas.
Como exemplos desses pacotes de softwares, pode-se citar os seguintes: SAP/R3, Oracle
Financial, Datasul e Microsiga.
2.4.5
Ferramentas de Apoio ao Controle de Versões e
Gerência de Configuração
Esse conjunto de ferramentas é aplicável ao processo de gestão de projetos em dois
âmbitos: o controle efetivo de versões dos diversos documentos eletrônicos gerados nos
processos de planejamento e controle de projetos e análise antecipada do impacto de
mudanças feitas em elementos do projeto.
As ferramentas destinadas ao controle de versões de documentos geralmente
permitem a criação de repositórios centrais que abrigam e controlam a utilização dos
documentos catalogados com base nas permissões atribuídas aos usuários. Quando alguém
deseja fazer uma alteração num documento, ele deve possuir direitos de acesso a esse
documento e solicitar à ferramenta o direito de escrita (check out) no mesmo. Ao término da
edição, a transação deve ser concluída com um comando de “devolução” do documento ao
repositório (check in). Neste instante o usuário pode registrar um breve relato das alterações
que foram feitas complementando o registro de histórico de alterações do documento em
questão. Análises comparativas podem ser feitas entre versões diferentes de um mesmo
documento, de tal forma que são apresentados, em destaque, os trechos que foram alterados.
Ferramentas destinadas ao controle de configuração, de certa forma estendem, as
de controle de versão comentadas anteriormente provendo mecanismos de auxílio aos
membros da equipe e stakeholders do projeto quanto à colaboração na análise de propostas e
aprovação de mudanças. Existem recursos que possibilitam o trabalho por meio da Internet
possibilitando a colaboração de membros e stakeholders que por ventura encontram-se
geograficamente distantes. Segundo a Rational (RATIONAL, 2002a), com ferramentas desse
36
tipo, as equipes e stakeholders do projeto podem avaliar requisitos, determinar seu impacto no
projeto e, quando aplicável, validar as alterações.
Alguns exemplos dessas ferramentas incluem softwares como os seguintes:
Rational ClearCase, Rational ClearQuest e Telelogic CM Synergy.
2.5 Resumo do Capítulo e Alguns Comentários
Neste capítulo foram expostos os principais conceitos da gestão de projetos,
definidos pelo PMBOK (PMI, 2000) e por outros autores. A gestão de projetos de larga escala
envolvendo parceiras é discutida apresentando o exemplo da EMBRAER, uma empresa do
setor aeronáutico que possui, dentre outros, o Programa EMBRAER 170/190 que envolve
projetos para o lançamento de quatro aeronaves comerciais, e para isso, conta com o apoio de
vários parceiros espalhados pelo mundo.
Frente à necessidade de viabilizar o desenvolvimento de projetos de forma
integrada com os parceiros, a EMBRAER concebeu uma solução baseada num Portal Web,
dotado de algumas funcionalidades de ambiente cooperativo, que é acessado pelos parceiros a
partir de uma rede privada de computadores. Uma desvantagem dessa solução é a exigência
de retrabalho, principalmente por parte dos parceiros, que controlam internamente o projeto
dos componentes que lhes foram delegados e necessitam redigitar informações para que a
EMBRAER faça a consolidação das mesmas e consiga realizar a gestão dos projetos de forma
eficaz.
Além disso, foram citadas e comentadas, as características básicas das diversas
ferramentas computacionais utilizadas pelos profissionais da área de gestão de projetos no
auxilio ao desenvolvimento de suas atividades.
Como principal resultado das investigações que propiciaram os relatos presentes
nesse capítulo cita-se a obtenção do embasamento necessário para realizar a especificação de
requisitos a serem contemplados no modelo de interoperabilidade computacional para a
gestão de projetos em parceria.
Este capítulo abordou o domínio do problema endereçado neste trabalho. O
próximo capítulo apresenta a tecnologia de serviços Web que foi investigada como alternativa
para a implementação da solução proposta, que é detalhada no Capítulo IV.
37
3 Capítulo III
O Software Como Serviço
Este capítulo apresenta conceitos relacionados com sistemas distribuídos, padrões
e tecnologias utilizadas na construção de unidades de programas capazes de serem acessadas
remotamente por meio de uma rede de computadores. Essas unidades de programas são
conhecidas como “serviços Web” e provêem uma forma eficiente de possibilitar o acesso
remoto a funcionalidades de software, propiciando a interoperabilidade de sistemas
concebidos a partir de plataformas distintas.
São apresentadas as tecnologias de suporte a serviços Web, uma proposta de
arquitetura de software orientada a serviços, especificações existentes e em desenvolvimento,
detalhes sobre desempenho e conceitos relacionados com a implementação desses serviços.
3.1 Sistemas Distribuídos e os Serviços Web
Segundo McCart e Cassady-Dorion (1998), um sistema distribuído é composto de
nós que executam computações. Ou seja, são unidades de computação como
microcomputadores, mainframe ou dispositivos portáteis capazes de conectarem à rede e
processar informações.
No termo “sistemas de objetos distribuídos” a palavra “distribuídos” conota
separação ou dispersão geográfica e a palavra “objetos” representa unidades de software que
encapsulam dados e comportamento. Objetos situados fora do sistema local são conhecidos
como objetos remotos. Sistemas que apresentam tais características são denominados sistemas
de objetos distribuídos, constituindo o resultado do casamento de duas tecnologias: redes e
programação orientada a objetos.
Nas fronteiras lógicas dos nós de um sistema distribuído encontram-se as
interfaces. Elas são as partes da arquitetura do sistema que estão expostas na rede e é a partir
delas que os nós interagem. É claro que para que essa interação aconteça é necessário definir
38
padrões. Interfaces padronizadas promovem interoperabilidade que é a habilidade de
componentes de software trabalharem juntos. Atualmente, várias organizações estão
empenhadas na definição de padrões que visam viabilizar a integração de sistemas.
A Figura 10 ilustra a estrutura física de um sistema distribuído de fraco
acoplamento na Internet. Pode-se citar, como exemplo, o cenário de uma multinacional com
um mainframe em sua sede e com microcomputadores, laptops e PDAs espalhados pelas
regiões onde possui filiais, no caso Brasil, Estados Unidos e Alemanha. Os nós desse sistema
utilizam tanto conexões privadas quanto conexões seguras por meio da Internet, para a
realização de eventuais processamentos que dependam de informações residentes nos demais
nós e/ou que atualizem informações nestes.
O termo “fraco acoplamento” indica que não existe uma dependência total das
partes que compõem o sistema, ou seja, elas são capazes de processar e armezar informações
localmente e, apenas quando necessário, elas comunicam entre sí trocando dados e realizando
processamentos.
Figura 10: Exemplo de Sistema Distribuído
39
As tecnologias de objetos distribuídos visam a “transparência de localização”
tornando mais fácil o acesso e utilização de objetos num nó remoto, como se este estivesse no
nó local. A transparência de localização envolve as seguintes funções:
•
Localização e carga de classes de objetos remotos;
•
Localização e referência a objetos remotos;
•
Invocação remota de métodos incluindo passagem de objetos como
parâmetros e o retorno de valores; e
•
Notificação de falhas de rede e outros problemas.
Como exemplos de tecnologias de objetos distribuídos pode-se citar: o Java
Remote Method Invocation (RMI) da Sun; o Distributed Component Object Model (DCOM)
da Microsoft; a Common Object Request Broker Architecture (CORBA) da Object
Management Group – OMG; e o Voyager da ObjectSpace, que é um pacote de classes capaz
de criar e controlar agentes de software (objetos móveis) baseados em Java. Maiores detalhes
sobre essas tecnologias podem ser obtidos em (McCARTY, 1998).
Vawter e Ronam (2001) classificam os serviços Web como a nova geração da
computação distribuída. Eles representam uma forma, diga-se “mais fácil” de implementar a
interoperabilidade em sistemas de objetos distribuídos, baseada principalmente em
tecnologias como XML (eXtensible Markup Language) e HTTP (Hipertext Transfer
Protocol).
Myron et all (2000), citando o IEEE (Institute of Electrical and Electronic
Engineers), apresenta o termo interoperabilidade, sob a perspectiva tecnológica, como sendo a
habilidade de dois ou mais sistemas trocarem informações, e mutuamente utilizarem as
informações que foram trocadas. Outras definições apresentadas por Myron et al, citando o
NIST (National Institute of Standards and Technology), o Arm Science Board e o DoD (US
Department of Defense), são semelhantes.
Costa (2002), diz que as tecnologias apontadas anteriormente (RMI, DCOM e
CORBA) tiveram a mesma intenção funcional, isto é, propiciar o desenvolvimento de
software de tal forma que utilizem componentes remotos como se estivessem acessíveis
localmente. Além de problemas de tratamento de parâmetros e atributos, tecnologias como
CORBA e DCOM, por exemplo, possuem uma série de limitações, apresentam certa
complexidade,
ambigüidade
semântica
e
exigem
um
considerável
esforço
de
desenvolvimento. Como os serviços Web são baseados em XML e esta, por sua vez, é
40
baseada em texto e é uma linguagem-padrão, a arquitetura de serviços Web pode ser
considerada de RPC (Remote Procedure Call) nos mesmos moldes de DCOM, CORBA e
RMI, porém com melhorias significativas em interoperabilidade e facilidade de
desenvolvimento. Uma das vantagens de serviços Web sobre CORBA é que eles não exigem
a utilização explícita de um ORB (Object Request Broker). Conceitualmente, existe uma
espécie de ORB para os serviços Web, porém, este já vem incorporado nas versões mais
recentes dos servidores de aplicação que suportam serviços Web como, por exemplo, o
WebSphere 5.0 da IBM, o BES da Borland e o WebLogic da BEA.
Costa (2002) afirma também, que a tecnologia de serviços Web não substitui as
tecnologias de objetos distribuídos existentes. Se usadas corretamente, essas tecnologias se
complementam e não competem entre si, pois têm paradigmas diferentes.
Serviços Web não são objetos no sentido formal e clássico de orientação a objetos,
o que não significa que não seja possível mapear objetos distribuídos neles. O modelo de
sistemas de objetos distribuídos deve ser construído tendo em mente que alguns dos objetos
distribuídos serão serviços Web chamados de Objetos de Serviço, que delegarão suas funções
a outros objetos que os sustentam.
A idéia fundamental deve ser a de que os objetos distribuídos são os blocos
essenciais de construção de serviços escaláveis e de alta disponibilidade numa empresa, e que
serviços Web são os pontos de acesso à utilização desses serviços, que permitem seu
compartilhamento com sistemas internos de outras empresas.
3.2 Conceituação de Serviços Web
“Serviços Web são componentes de software com baixo fator de acoplamento, utilizados
por meio de padrões de tecnologia da Internet. Um serviço Web representa uma função de negócio ou
um serviço que pode ser acessado por uma outra aplicação, sobre redes públicas e, geralmente,
disponibilizado por protocolos conhecidos” (COSTA, 2002).
Num aspecto mais técnico, os serviços Web expõem a funcionalidade do negócio
por meio da rede, incluindo a Internet (IONA, 2002a). Pode-se expandir essa definição a
partir de dois pontos:
•
Exposição dos serviços do negócio, que envolve:
o A identificação ou definição dos valores das funções ou processos
comerciais;
41
o A definição de interfaces baseada em serviços para tais processos; e
o A descrição daquelas interfaces num formato adequado para a Web.
•
Disponibilizar os serviços de negócio por meio de uma rede de
computadores, envolvendo o seguinte:
o A publicação da interface de serviços a fim de que ela possa ser
descoberta e utilizada por clientes e parceiros;
o A aceitação de solicitações e envio de respostas, utilizando-se os
padrões e mensagens XML; e
o Estabelecimento
da
ligação
entre
as
solicitações
externas
(basicamente de fora da “linha guarda-fogo” (firewall), utilizandose protocolos da Web) e a implementação das funções comerciais
(dentro da ”linha guarda-fogo” (firewall), utilizando-se protocolos
padrões e de propriedade da empresa).
Costa (2002) apresenta dois grandes casos que devem ser considerados quando da
utilização das tecnologias de serviços Web: serviços Web intraWebs (protegidos por um
firewall) e serviços Web interWebs (acessíveis via Internet).
Segundo a IONA Technologies (2002b), dentro do contexto de serviços Web, as
empresas precisam ser capazes de realizar o seguinte:
•
Publicar a descrição de seus serviços e dados comerciais, do mesmo
modo que atualmente publicam as páginas HTML, de forma que as
outras empresas possam encontrar e usá-las;
•
Buscar e encontrar as descrições dos serviços, publicadas por outras
empresas, sejam parceiras ou aquelas com as quais elas desejariam se
comunicar; e
•
Interagir com os serviços publicados e implementados por outras
empresas, e permitir que estas interajam com seus serviços, conforme
acordos comerciais e parcerias.
A Figura 11 ilustra os papéis, operações básicas e os principais elementos
pertencentes ao contexto dos serviços Web.
42
Figura 11: Papéis e Operações no Contexto dos Serviço Web.
O provedor expõe funcionalidades de seus sistemas, na forma de serviços Web,
publicando descrições dos mesmos internamente e/ou num divulgador. O Consumidor realiza
uma busca pelas descrições desses serviços e ao obtê-las, ele consegue implementar unidades
de sofware capazes de interagir com os sistemas do provedor.
O papel de divulgador geralmente é exercido por organizações que disponibilizam
repositórios e portais que permitem aos provedores registrarem informações sobre seus
negócios e seus serviços Web, e aos consumidores, consultarem e obterem tais informações.
Como exemplos de divulgadores pode-se citar: a IBM, e a Microsoft.
Os serviços Web representam uma forma consideravelmente simples e eficiente de
se promover a integração de sistemas, seja entre sistemas existentes dentro das fronteiras da
organização, seja entre sistemas existentes em organizações distintas.
Uma série de empresas como Microsoft, IBM, IONA, BEA e Oracle oferecem
soluções para implementação de serviços Web e em alguns casos, se unem para definir
padrões, uma exigência da integração de sistemas.
Essas empresas apóiam seus produtos em duas plataformas de desenvolvimento de
software. De um lado, e sozinha, a Microsoft que aposta na .NET, e do outro, as demais, que
baseiam sua solução na plataforma J2EE (Java To Enterprise Edition) da Sun Microsystems.
43
Detalhes sobre o desenvolvimento de serviços Web nessas duas plataformas são abordados
nas Seções 3.8, 3.9 e 3.10.
3.3 Tecnologias de Suporte aos Serviços Web
Pela própria proposta dos serviços Web, percebe-se que seu desenvolvimento
exige a utilização de diversas tecnologias no sentido de se implementar mecanismos que
possibilitem as operações de publicação e procura, bem como a interação de sistemas por
meio deles. Porém, as principais tecnologias diretamente relacionadas com serviços Web são
as seguintes:
•
XML,
incluindo
esquemas
(schemas),
analisadores
gramaticais
e
ferramentas de transformação XML (parsers);
•
Protocolo SOAP (Simple Object Access Protocol), que é a utilização
específica do XML como um protocolo de comunicação aplicação-paraaplicação;
•
Linguagem WSDL (Web Service Description Language), um formato
específico do Esquema XML para descrever as mensagens dos serviços
Web, operações e mapeamentos de protocolo; e
•
UDDI (Universal Description, Discovery and Integration), padrão utilizado
para implementar repositórios para arquivamento e busca de descrições dos
serviços Web.
A Figura 12 exibe a estrutura básica de serviços Web, exemplificando a alocação
dessas tecnologias nos elementos mostrados na Figura 11. Vale salientar que XML não
aparece explicitamente, pois ela é utilizada para implementar outras, como a WSDL e o
SOAP, por exemplo. Outros elementos como ebXML, BizTalk e o contêiner dos serviços
Web são devidamente comentados em seções específicas deste trabalho.
44
Figura 12: Estrutura Básica dos Serviços Web.
A tecnologia dos serviços Web utiliza o padrão XML e outros para expor
funcionalidades, implementadas em softwares, na Web. Os serviços Web são descritos em
documentos WSDL, que são referenciados e/ou armazenados em repositórios UDDI
geralmente providos por empresas que desempenham o papel de divulgadores. Nada impede
que documentos WSDL possam ser obtidos diretamente de provedores, pois a função dos
divulgadores é simplesmente facilitar a descoberta do serviço.
Quando um consumidor descobre o serviço Web, ele implementa a porção
consumidora que é capaz de invocá-lo por meio da rede, enviando mensagens SOAP sobre o
protocolo HTTP ou HTTPS (a forma segura do protocolo HTTP). Essas mensagens
combinam com a descrição WSDL, geralmente obtida a partir do servidor UDDI de um
divulgador, ou diretamente do provedor.
A utilização dos protocolos HTTP ou HTTPS, para transporte, permite às
invocações das aplicações consumidoras transporem dispositivos de segurança de redes
conhecidos como Firewalls.
As principais tecnologias relacionadas com serviços Web são detalhadas nas
subseções a seguir.
45
3.3.1
A Linguagem de Marcação Estendida - XML
XML é uma linguagem de marcação extensível, similar a HTML. A principal
diferença entre elas é que enquanto HTML se aplica à apresentação das informações, a XML
se aplica à definição delas, sendo então utilizada para descrever estruturas de dados. Enquanto
a HTML possui tags prédefinidas, a XML não, permitindo ao desenvolvedor definir suas
próprias tags que especificam elementos de dados.
A estrutura básica de um documento XML é composta por elementos, atributos e
valores associados a esses atributos e elementos. Na Figura 13 apresenta-se um exemplo de
documento XML que, na parte superior exibe o documento e na parte inferior detalha este
mesmo documento evidenciando os componentes de sua estrutura básica que é formada por
elementos, valores de elementos, atributos de elementos e valores de atributos de elementos.
Figura 13: Exemplo de um Documento XML Evidenciando sua Estrutura Básica.
46
Este documento pode, por exemplo, ser aplicado na integração de sistemas de
gestão de projetos, uma vez que sua estrutura foi definida de forma a propiciar a comunicação
do desempenho de um elemento da WBS definido pela empresa líder do projeto, cuja
execução foi delegada a uma empresa parceira do projeto.
A XML foi apresentada pela primeira vez pelo W3C (World Wide Web
Consortium) em 1998 e tem sido largamente adotada como formato independente de
representação de dados, o que representa uma boa alternativa para criação de arquivos de
configuração, intercâmbio de dados, transações B2B incluindo a representação de chamadas
para objetos distribuídos por meio do SOAP, que é uma aplicação de XML.
Dentre as vantagens da XML pode-se destacar que ela é de fácil leitura, fácil
transformação, extensível e adaptável. Além disso, pode ser definida uma gramática por meio
de um DTD (Document Type Definition) ou de um XSD (XML Schema Definition) para forçar
o uso de uma sintaxe específica. Tais características transformam a XML numa das principais
tecnologias utilizadas para a construção de serviços Web. Algo importante sobre a XML é que
ela não é usada somente como formato de mensagens, mas também, como o modo pelo qual
as próprias mensagens são definidas. Sendo assim, é importante saber um pouco sobre ela,
especialmente dentro do contexto dos serviços Web.
Documentos DTD e XSD são conhecidos como modelos de conteúdo (content
models) que podem ser associados a documentos XML para restringir ou confinar um
determinado uso da XML para um fim específico. O XSD é mais flexível e completo que o
DTD tendendo a substituí-lo com o tempo. A Figura 14 e a Figura 15, ilustram exemplos de
documentos de cada um desses dois modelos.
Figura 14: Exemplo de um Documento DTD.
47
Figura 15: Exemplo de Documento XSD.
Nota-se nos exemplos de DTD e XSD, apresentados na Figura 14 e na Figura 15,
que eles descrevem o documento XML apresentado na Figura 13. Nota-se também que o XSD
é mais completo especificando inclusive, o tipo do valor associado a um atributo ou elemento.
A XML não produz aplicativos executáveis. Ela é, simplesmente, uma linguagem
bastante flexível para representar entidades.
Serviços Web são desenvolvidos a partir de componentes de software, como EJB
(Enterprise Java Beans), por exemplo, que são mapeados para documentos XML. As
chamadas e respostas a esses serviços também são feitas com base em XML.
Plataformas de desenvolvimento de software como J2EE e .NET possuem um
conjunto de classes que implementam parsers. Os parsers são API’s (Application Program
Interface) prontas para o desenvolvimento de programas capazes de transformar documentos
XML em objetos e vice-versa. Os principais parsers são o SAX (Simple API for XML
Parsing) e o DOM (Document Object Model), cada um apresenta uma forma específica de
lidar com os documentos XML mapeando-os para objetos.
A flexibilidade de uso da XML “dá asas à imaginação” de vários desenvolvedores,
que constantemente estão criando tecnologias baseadas nela. Isso vem exigindo a definição de
padrões para que seu uso seja mais eficiente. Um exemplo de inconveniência gerado por essa
flexibilidade é, por exemplo, o conflito de nomes de elementos e atributos. Para solucionar
isto, foram definidos os XML Namespaces que permitem a qualificação de elementos e
48
atributos por meio do uso de prefixos nos nomes ou de um atributo pré-definido, chamado
xmlns. Esse recurso é de grande importância na implementação de serviços Web para se
qualificar os elementos e atributos que são mapeados de/para objetos.
Uma boa referência à XML e às tecnologias que a cercam, pode ser encontrada em
(AHMED,2001 et al) e no sítio Web http://www.w3.org .
3.3.2
O Protocolo de Comunicação SOAP
O protocolo SOAP (Simple Object Access Protocol) é uma estrutura de mensagem
baseada em XML, projetada especificamente para a troca de dados formatados por meio da
Internet (IONA 2002b). Ele provê um protocolo de comunicação abstrato, independente,
capaz de conectar dois ou mais portais de empresas ou sistemas remotos. Usando SOAP,
empresas podem interagir usando serviços (ou interfaces) que trocam mensagens XML
autodescritas.
A especificação do SOAP está disponível a partir do sítio Web do W3C
(http://www.w3c.org). Ela foi proposta conjuntamente pela Microsoft, IBM e Userland
Software em maio de 2000 e basicamente suporta dois formatos de mensagem XML:
•
Autodescritivo, para troca de documentos no estilo EAI (Enterprise
Application Integration) e EDI (Electronic Data Interchange); e
•
Interações no estilo RPC (Remote Procedure Call), que modelam os
métodos de objetos e seus parâmetros.
Este protocolo descreve como os tipos de dados, definidos em esquemas XML
associados, podem ser serializados, ou enfileirados sobre transmissões HTTP ou outra.
As mensagens SOAP consistem de três partes primárias: o envelope, o cabeçalho e
o corpo da mensagem. A Figura 16 ilustra essa estrutura que é descrita a seguir.
O envelope, identificado pelo elemento envelope, define um pacote para
descrever o que contém uma mensagem e como processá-la. Ele basicamente marca o início e
o fim da mensagem SOAP, embora as mensagens possam ter links para objetos fora dele.
Como pode ser observado na Figura 16, o envelope pode conter um cabeçalho e
necessariamente, um corpo. Ele também permite a especificação de um conjunto de regras de
codificação em que tanto o provedor quanto o consumidor de serviços Web podem concordar
com elas, normalmente por meio do download do mesmo esquema XML que as define.
49
O cabeçalho, identificado pelo elemento header, é opcional e pode ser usado para
incluir informações sobre o estilo de interação RPC, se necessário, ou para carregar
informações gerais sobre a mensagem, como informação de segurança, endereços para envio
da mensagem, se houver, e parâmetros de negociação, como por exemplo, códigos de
pagamento.
Uma mensagem SOAP pode incluir nenhum ou qualquer número de cabeçalhos.
Eles incluem um mecanismo chamado “must understand” (“deve-se entender”), que permite
aos provedores e consumidores negociarem acordos ao suporte de um dado cabeçalho ou
conjunto de cabeçalhos. Trata-se de um atributo do tipo booleano que aceita os valores true,
false, 0 ou 1, e se ele tiver valor true, o receptor da mensagem deve dar suporte ao que foi
definido (uma transação por exemplo), caso contrário, a recepção dessa mensagem gerará um
erro.
O corpo, identificado pelo elemento body, carrega os dados da mensagem ou
documento enviado. Ele contém dados formatados como uma estrutura simples, amplamente
autodescritiva ou uma interface estilo RPC com nomes de métodos e parâmetros. Elementos
da mensagem SOAP são definidos usando-se esquemas e namespaces XML qualificados.
Figura 16: Estrutura Básica de uma Mensagem SOAP.
A Figura 17 e a Figura 18, mostram um exemplo da definição de mensagens
SOAP referentes a um pedido (request) e uma resposta (response) à invocação de um Serviço
Web. Nota-se que existe uma diferença entre a estrutura do corpo da mensagem apresentada
tanto na Figura 17 quanto na Figura 18, em relação à estrutura do documento exibido na
50
Figura 13. Isto ilustra a flexibilidade da XML para definição de dados, na qual determinados
dados, como partnerId, por exemplo, são representados na Figura 13 por atributos de
elementos e na Figura 17 e na Figura 18, quando as mensagem estiverem montadas, este dado
será representado por um elemento.
Figura 17: Exemplo de Definição de uma Mensagem SOAP para Requisição de um Serviço Web.
Figura 18: Exemplo de Definição de uma Mensagem SOAP em Resposta à Solicitação de um Serviço Web.
51
Quando a mensagem é montada pelo servidor SOAP, os textos contendo tipos de
dados (string, dateTime,decimal) são substituídos por valores efetivos.
3.3.3
A Linguagem de Descrição de Serviços Web –
WSDL
Em computação distribuída, o problema de como descrever uma interface de um
componente em particular e expô-la para que desenvolvedores remotos possam escrever
códigos que as acessam persiste, mesmo que em menor escala, desde o início dessa
modalidade de computação. O OMG (Object Management Group) solucionou esse problema
para a arquitetura de componentes distribuídos, no caso de CORBA, com a definição da IDL
(Interface Definition Language) que provê uma linguagem neutra para descrever assinaturas
de métodos de um componente, incluindo informações sobre: que parâmetros esses métodos
aceitam, que tipo de dados eles retornam e que exceções eles lançam. “A WSDL (Web Service
Description Language) é a IDL dos serviços Web” (AHMED, 2001b). Trata-se de uma forma
particular de um esquema XML, desenvolvido pela Microsoft e a IBM, que permite descrever
serviços Web, incluindo a descrição de como os consumidores podem interagir com eles.
Segundo o W3C (WORLD, 2002a) um esquema WSDL cria definições de
serviços Web baseadas em seis componentes descritivos que expressam “como” e “onde”
uma funcionalidade é ofertada. Os componentes descritivos de um esquema WSDL são os
seguintes:
•
Componente de descrição de tipos (Types);
•
Componente de descrição de mensagens (Messages);
•
Componente de descrição de tipos de portas (portTypes);
•
Componente de descrição de tipos de serviços (serviceTypes);
•
Componente de descrição de ligações (bindings); e
•
Componente de descrição de serviços (services).
Todo componente de descrição, com exceção do componente de descrição Type
exige a definição da propriedade name. O valor dessa propriedade combinado com o valor da
propriedade targetNamespace forma um nome qualificado (Qualified Name- QName) que
identifica de forma única o componente de descrição dentre os demais, da mesma espécie. Os
seis componentes descritivos são descritos a seguir.
52
O componente de descrição de tipos (types) descreve os tipos de dados com os
quais o serviço opera. O W3C sugere que utilize sempre os tipos de dados definidos no XML
Schema: DataType, uma padronização de nomes de tipos de dados para esquemas XML
definida em (WORLD, 2002b), no intuito de aumentar a interoperabilidade entre sistemas que
utilizam XML para troca de dados. Um WSDL deve ter no máximo um elemento types.
O componente de descrição de mensagens (message) descreve quais mensagens
o serviço entende ou pode enviar a outros serviços Web. Um elemento message define
logicamente um “tipo” de mensagem que pode ser usado para definir uma mensagem de
entrada, saída ou falha associada a uma operação (elemento operation na WSDL) de um
componente de descrição portType. Um documento WSDL pode conter zero ou mais
elementos de descrição de mensagens.
O componente de descrição de tipos de portas (portType) contém uma ou mais
descrições de operações (operation) oferecidas pelo serviço. Cada elemento operation deve
ser identificado de forma única no documento por meio do atributo name. Opcionalmente,
pode-se definir a propriedade documentation de cada operation fornecendo maiores
detalhes a respeito da operação que se está definindo. Além disso, um elemento operation
pode ter associado uma mensagem de entrada (elemento input), uma mensagem de saída
(elemento output) e zero ou mais mensagens de falha (elemento fault), definidas no
componente de descrição de mensagens.
Existem combinações de mensagens de entrada e saída de operações que geram
quatro comportamentos de operações: Input-Output Operations, Input-Only Operations,
Output-Input Operations e Output-Only Operations.
Parâmetros de entrada e saída podem ser especificados por meio do elemento Part,
e o que define se eles são de entrada ou saída é o tipo de mensagem à qual eles estão
associados, input ou output.
O componente de descrição de tipos de serviços (serviceType) define o
agrupamento de um conjunto de elementos portType. Um componente de descrição de
serviço (service) refere-se a uma descrição serviceType para indicar a funcionalidade
abstrata oferecida pelo serviço. Um componente de descrição serviceType identifica um ou
mais componentes de descrição portType por meio de seu atributo QName.
O componente de descrição de ligações (binding) provê um framework para tratar
detalhes de ligações. Eles são utilizados para indicar como as mensagens devem ser
formatadas, quando são enviadas ou recebidas de serviços. Além disso, eles também são
utilizados para indicar o protocolo de transporte a ser utilizado na comunicação, que não pode
53
ser mais do que um. Um componente de descrição binding requer que a propriedade type seja
preenchida com o QName de um componente de descrição portType. Outro detalhe é que
ele contém uma ou mais propriedades ligação que são aplicáveis às operações (operation),
definidas no componente portType.
O componente de descrição de serviços (service) define um serviço Web como
sendo uma coleção de portas. Uma porta se restringe a um portType, incluindo a
especificação de endereços (end-points) a partir do qual o serviço está disponível. Além da
propriedade name, requerida para se constituir o nome qualificado (QName) do serviço, é
requerida especificação do QName de um componente de descrição serviceType. Um
componente service contém um ou mais componentes de descrição de porta (port) que requer
o seguinte:
•
Identificação única dentre o grupo de descrições;
•
Associação de um componente de descrição de ligação (binding) que indica
como as mensagens enviadas de/para essa porta devem ser formatadas; e
•
Especificação de um endereço (end-point) pelo qual as mensagens devem
ser enviadas para alcançar operações de um componente portType
referenciado num componente binding.
Opcionalmente, pode-se atribuir valor à propriedade documentation para se
fornecer detalhes a respeito da porta.
Um componente service pode conter uma ou mais propriedades de ligação
adicionais às propriedades das portas. Conhecidos os componentes do documento WSDL
pode-se entender a estrutura completa de um serviço Web. A Figura 19 apresenta um exemplo
abstrato de um documento WSDL completo. Antes, porém, as seguintes definições são
necessárias:
•
Os caracteres que sucedem elementos e atributos “?”, “*” e “+” representam
a quantidade possível de ocorrências do elemento no documento, sendo
respectivamente: “zero ou um”, “zero ou mais” e “um ou mais”; e
•
Elementos terminando com reticências (“...”) indica que os demais atributos
são irrelevantes no contexto do exemplo.
54
Figura 19: Estrutura de um Documento WSDL.
55
Dada a complexidade dos documentos WSDL, em função de seu tamanho e
ligação de informação entre os componentes descritivos, os desenvolvedores geralmente
utilizam ferramentas para gerá-los a partir dos códigos-fonte produzidos. Ambientes de
desenvolvimento de software como o WSAD – WebSphere Application Developer da IBM, o
JBuilder Web Service Kit da Borland e o Microsoft Visual Studio .NET possuem esse tipo de
ferramenta.
Na listagem abaixo apresenta-se o documento WSDL gerado por meio do
Microsoft Visual Studio .NET, para o exemplo do serviço Web PerformanceReportWS,
que vem sido citado. Nota-se que existe uma diferença na definição dos elementos em relação
ao exemplo de documento apresentado na Figura 19, no qual o prefixo wsdl:, constante no
modelo, não é apresentado ou foi substituído por s:. Isso é uma questão de namespace, o que
não impede o processamento correto do documento. Alguns elementos foram colocados em
negrito apenas para destacá-los.
<?xml version="1.0" encoding="utf-8" ?>
<definitions xmlns:http=http://schemas.xmlsoap.org/wsdl/http/ xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:s="http://www.w3.org/2001/XMLSchema" xmlns:s0="http://tempuri.org/"
xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:tm="http://microsoft.com/wsdl/mime/textMatching/"
xmlns:mime="http://schemas.xmlsoap.org/wsdl/mime/" targetNamespace="http://tempuri.org/"
xmlns="http://schemas.xmlsoap.org/wsdl/">
<types>
<s:schema elementFormDefault="qualified" targetNamespace="http://tempuri.org/">
<s:element name="getPerformanceInfo">
<s:complexType>
<s:sequence>
<s:element minOccurs="0" maxOccurs="1" name="partnerID_" type="s:string" />
<s:element minOccurs="0" maxOccurs="1" name="projectID_" type="s:string" />
<s:element minOccurs="0" maxOccurs="1" name="wbsItemID_" type="s:string" />
</s:sequence>
</s:complexType>
</s:element>
<s:element name="getPerformanceInfoResponse">
<s:complexType>
<s:sequence>
<s:element minOccurs="0" maxOccurs="1" name="getPerformanceInfoResult"
type="s0:PerformanceInfo" />
</s:sequence>
</s:complexType>
</s:element>
<s:complexType name="PerformanceInfo">
<s:sequence>
<s:element minOccurs="0" maxOccurs="1" name="PartnerID" type="s:string" />
<s:element minOccurs="0" maxOccurs="1" name="ProjectID" type="s:string" />
<s:element minOccurs="0" maxOccurs="1" name="WBSItemID" type="s:string" />
<s:element minOccurs="0" maxOccurs="1" name="WBSItemDescr" type="s:string" />
<s:element minOccurs="1" maxOccurs="1" name="BaseLine" type="s:dateTime" />
<s:element minOccurs="1" maxOccurs="1" name="PlannedValue" type="s:decimal" />
<s:element minOccurs="1" maxOccurs="1" name="EarnedValue" type="s:decimal" />
<s:element minOccurs="1" maxOccurs="1" name="ActualCost" type="s:decimal" />
</s:sequence>
</s:complexType>
<s:element name="PerformanceInfo" nillable="true" type="s0:PerformanceInfo" />
</s:schema>
</types>
56
<message name="getPerformanceInfoSoapIn">
<part name="parameters" element="s0:getPerformanceInfo" />
</message>
<message name="getPerformanceInfoSoapOut">
<part name="parameters" element="s0:getPerformanceInfoResponse" />
</message>
<message name="getPerformanceInfoHttpGetIn">
<part name="partnerID_" type="s:string" />
<part name="projectID_" type="s:string" />
<part name="wbsItemID_" type="s:string" />
</message>
<message name="getPerformanceInfoHttpGetOut">
<part name="Body" element="s0:PerformanceInfo" />
</message>
<message name="getPerformanceInfoHttpPostIn">
<part name="partnerID_" type="s:string" />
<part name="projectID_" type="s:string" />
<part name="wbsItemID_" type="s:string" />
</message>
<message name="getPerformanceInfoHttpPostOut">
<part name="Body" element="s0:PerformanceInfo" />
</message>
<portType name="PerformanceReportWSSoap">
<operation name="getPerformanceInfo">
<input message="s0:getPerformanceInfoSoapIn" />
<output message="s0:getPerformanceInfoSoapOut" />
</operation>
</portType>
<portType name="PerformanceReportWSHttpGet">
<input message="s0:getPerformanceInfoHttpGetIn" />
<output message="s0:getPerformanceInfoHttpGetOut" />
</operation>
</portType>
<portType name="PerformanceReportWSHttpPost">
<input message="s0:getPerformanceInfoHttpPostIn" />
<output message="s0:getPerformanceInfoHttpPostOut" />
</operation>
</portType>
<binding name="PerformanceReportWSSoap" type="s0:PerformanceReportWSSoap">
<soap:binding transport="http://schemas.xmlsoap.org/soap/http" style="document" />
<soap:operation soapAction="http://tempuri.org/getPerformanceInfo" style="document" />
<input>
<soap:body use="literal" />
</input>
<output>
<soap:body use="literal" />
</output>
</operation>
</binding>
<binding name="PerformanceReportWSHttpGet" type="s0:PerformanceReportWSHttpGet">
<http:binding verb="GET" />
<http:operation location="/getPerformanceInfo" />
<input>
<http:urlEncoded />
</input>
<output>
<mime:mimeXml part="Body" />
</output>
</operation>
</binding>
<binding name="PerformanceReportWSHttpPost" type="s0:PerformanceReportWSHttpPost">
<http:binding verb="POST" />
<http:operation location="/getPerformanceInfo" />
57
<input>
<mime:content type="application/x-www-form-urlencoded" />
</input>
<output>
<mime:mimeXml part="Body" />
</output>
</operation>
</binding>
<service name="PerformanceReportWS">
<port name="PerformanceReportWSSoap" binding="s0:PerformanceReportWSSoap">
<soap:address location="http://localhost/eProject/PerformanceReportWS.asmx" />
</port>
<port name="PerformanceReportWSHttpGet" binding="s0:PerformanceReportWSHttpGet">
<http:address location="http://localhost/eProject/PerformanceReportWS.asmx" />
</port>
<port name="PerformanceReportWSHttpPost" binding="s0:PerformanceReportWSHttpPost">
<http:address location="http://localhost/eProject/PerformanceReportWS.asmx" />
</port>
</service>
</definitions>
3.3.4
O Serviço de Publicação de Serviços Web – UDDI
Curbera et al. (2002) citam que a especificação UDDI (Universal Description,
Discovery and Integration) provê uma forma independente de plataforma, pois é baseada em
XML, de descrever serviços, descobrir negócios e integrar serviços de negócio usando a
Internet. Ela é uma iniciativa que foi desenhada para permitir que as organizações realizem
transações entre si de maneira mais rápida, fácil e dinâmica, ou seja, que se encontrem e se
comuniquem.
A UDDI é uma iniciativa das empresas Microsoft, IBM e Ariba cuja especificação
completa se encontra no sítio Web http://www.uddi.org.
WSDL e UDDI se complementam no sentido que a primeira provê um padrão para
descrição de interfaces abstratas e protocolos de ligação (binding protocols) de serviços de
rede arbitrários, e a segunda, possibilita a localização dessas descrições e informações a
respeito da empresa que as disponibiliza.
Costa (2002) aponta que registros UDDI incluem dados com: contatos da empresa,
como se comunicar com eles, uma lista de serviços disponíveis e como utilizá-lo por meio de
algum tipo de programação. Sendo assim, um serviço de UDDI é um grande catálogo, e em
teoria, um desenvolvedor pode procurar nele um serviço Web, descobrir como se conectar a
ele e utilizá-lo em sua aplicação.
58
UDDI define serviços em termos de um provedor que é descrito como uma
entidade de negócio (businessEntity) que oferece serviços de negócio (businessService)
que por sua vez são uma coleção de serviços Web, agrupados para prover um grupo de
serviços lógico, como “compras” ou “serviços de informação”, por exemplo. Uma entidade
pode oferecer qualquer número de serviços.
Os serviços Web são localizados e descritos por meio de modelos de ligação
(bindingTemplate) que descrevem onde ele está localizado, e provê informações de como
acessá-lo.
Informações descritivas sobre todos os tipos de dados chaves do UDDI, como por
exemplo, qual o ramo de negócio de uma empresa, que tipo de serviço ela oferece e que
interface deveria ser usada para ativar um serviço, são armazenados em objetos meta-dados
chamados de Technical Model (tModel), e quando são criados, recebem chaves de
identificação únicas.
Pode-se afirmar que UDDI é um serviço prestado pelas empresas que o definiram
e outras que estão aderindo à idéia. Os provedores de serviços Web devem registrar várias
informações cadastrais para serem uma entidade de negócio (business entity) capaz de
publicar seus serviços (business services). Isso disponibiliza aos provedores de registro UDDI
uma grande base de informações sobre essas empresas, uma vez que esses dados estão
hospedados em seus servidores.
Várias informações a respeito de UDDI podem ser obtidas a partir dos seguintes
sites, que também permitem o acesso e utilização desse serviço:
•
http://uddi.microsoft.com;
•
http://www.ibm.com/services/uddi/; e
•
http://uddi.ariba.com/.
A Figura 20 (CURBERA, 2002) ilustra a estrutura de dados referente ao registro
UDDI de uma business entity, e os detalhes de como e onde o serviço é acessado e provido
por uma ou mais estruturas binding template.
Um bindingTemplate especifica um endereço de acesso numa rede (no elemento
accessPoint) e um conjunto de tModels que descrevem o serviço. O apontamento para um
registro tModel é feito por meio de um atributo chamado tModelKey.
59
Figura 20: Estrutura da Dados de um Registro UDDI de uma businesEntity.
A Figura 21 e a Figura 22 mostram um exemplo abstrato de um registro de
businessService contendo bindingTemplates que referenciam registros tModel.
Figura 21: Exemplo Abstrato de um Registro UDDI de Serviço de Negócio (businessService).
Um elemento bindingTemplate é criado para cada ponto de acesso de serviço. O
endereço de rede do ponto de acesso é especificado no elemento accessPoint.
60
Um elemento tModelInstanceInfo é criado dentro do elemento bindingTemplate
para cada tModel.
Figura 22: Exemplo Abstrato de um Registro UDDI tModel
A Microsoft criou uma tecnologia denominada DISCO que também possibilita a
publicação e descoberta de serviços Web, porém de forma mais simples e limitada que o
serviço UDDI. Trata-se de um arquivo XML com a extensão .disco que é alojado num
servidor web que também hospeda os serviços Web, nesse caso, o servidor Web IIS da
Microsoft. Esta solução tem sido utilizada para serviços Web desenvolvidos na plataforma
Microsoft .NET, geralmente, de uso interno nas organizações. Detalhes sobre o DISCO
podem ser obtidos em Skonnard (2002) e no sítio Web http://www.msdn.microsoft.com.
Segundo Costa (2002), várias questões de qualidade, confiabilidade e dependência
não estão formalmente definidas em relação a UDDI. Como exemplo, as seguintes questões
permanecem:
•
Qual a veracidade da informação do registro?
•
Qual a escalabilidade do serviço?
•
Quem garante sua qualidade?
•
Qual o processo de atualização do serviço?
•
Como é o controle e a comunicação de novas versões para um serviço?
•
Quem garante a manutenção de versões anteriores?
•
Como comparar serviços?
61
Atualmente, a utilização de UDDI é definida apenas como um mecanismo de
comunicação e só poderá ser um repositório em larga escala, entre as organizações quando
essas questões forem resolvidas. Dentro de uma empresa, porém, já é possível usar esse
modelo de UDDI como um repositório central para publicar os serviços que estão sendo
desenvolvidos.
Assim como os documentos WSDL, os documentos de registro de UDDI também
podem ser gerados com o auxílio de ferramentas.
3.4 Arquiteturas de Aplicativos e Interação de Serviços
Web
Em Costa (2002) é apresentada uma proposta de arquitetura para aplicativos
orientados a serviço e uma forma de interação entre eles.
A arquitetura de aplicações em três camadas representa uma das formas mais
lógicas de se organizar componentes. Ela é constituída de uma camada de apresentação ou
interface com usuários, uma camada de aplicação ou regras de negócio que implementa os
processos referentes ao negócio da organização e por sua vez interagem com a camada de
apresentação e com a camada de dados, que é a terceira camada, responsável pela persistência
e recuperação de dados de objetos.
Numa arquitetura orientada a serviços, nem todos os objetos de negócio são
candidatos naturais a se tornarem serviços Web. Sendo assim, é necessário definir quais
objetos terão interfaces que serão publicadas como serviços e quais comporão as partes
necessárias para prover toda a funcionalidade da aplicação em si. Com base nisso, foi definido
um modelo básico em seis camadas, considerado apropriado ao desenvolvimento de
aplicativos que visem prover serviços Web. Em alguns casos, o número de camadas pode ser
reduzido a quatro. A Figura 23, baseada em Costa (2002), ilustra as duas arquiteturas de
aplicativos citadas e o mapeamento de uma para a outra. Os elementos da arquitetura proposta
são descritos a seguir.
62
Figura 23: Proposta de Arquitetura para Aplicativos Orientados a Serviço.
A Camada de Serviços de Apresentação contempla os diversos componentes
diretamente relacionados com as interfaces de usuário. É dependente de dispositivo, uma vez
que contém os elementos finais de apresentação.
A Camada de Lógicas de Apresentação manipula a apresentação dos
elementos visuais que compõem a aplicação, considerando fatores como a ordem desses
elementos e a validação das informações pelas regras de negócio (por meio de consulta à
camada que contém as regras de negócio). Aqui, são preparadas as informações a serem
exibidas de acordo com o dispositivo, como computador pessoal, palm e telefone celular.
A Camada de Serviços de Aplicação é uma camada lógica que mantém e
disponibiliza o negócio para os usuários. É nela que são alojados os componentes
desenvolvidos seguindo os conceitos de serviços Web. Esses componentes podem ser
publicados num serviço de UDDI, permitindo sua utilização por outros sistemas.
A Camada de Lógicas de Negócio compreende, basicamente, o tratamento das
regras de negócio pertinentes à aplicação. Ela representa o núcleo da aplicação, onde as
diversas considerações e regras estarão protegidas da intervenção das demais camadas.
63
A Camada de Acesso a Banco de Dados propõe a abstração do acesso aos
dados armazenados na camada SGBD pela camada imediatamente superior a essa: a de lógica
de negócio.
Por fim, a Camada de SGBD refere-se à base de dados em termos físicos, ou
seja, é o SGBD (Sistema Gerenciador de Banco de Dados) que armazena os dados que dizem
respeito à aplicação.
Considerando que os novos aplicativos sejam concebidos com essa arquitetura,
cria-se, automaticamente, um conjunto real de possibilidades de integração funcional entre
aplicativos que podem ou não estar dentro de uma mesma organização.
A Figura 24, também desenvolvida com base em Costa (2002), apresenta como,
conceitualmente, dois aplicativos desenvolvidos numa arquitetura orientada a serviços
poderiam se comunicar e criar uma interação entre seus processos.
Figura 24: Integração de Aplicativos Construídos em Arquiteturas Orientadas a Serviço
Com relação à interação de serviços Web, a Sun Microsystems em (SUN, 2002b)
classifica os serviços Web em dois tipos: os serviços Web Orientados a Chamada de
Procedimento Remoto (RPC) e os serviços Web Orientados a Documentos. Esses dois tipos
apresentam modelos de interação e processamento distintos. O Modelo de Interação refere-se
64
à forma como os consumidores geralmente invocam serviços hospedados num servidor, e o
Modelo de Processamento de serviços Web refere-se à forma como esses servidores
geralmente processam essas solicitações. Esses dois modelos utilizam Tipos de Interação
distintas, classificadas em síncronas e assíncronas. A Tabela 4, extraída de (SUN, 2002b)
ilustra melhor esses modelos.
Tabela 4: Modelos de Serviços Web
Serviço Web
Orientado a RPC
Orientado a Documentos
Mensagens (ou
Modelo de Interação
RPC
RPC com XML
atachado)
(Negócios)
Modelo de
Centrado em
Processamento
Objetos
Tipo de Interação
Síncrona
Centrado em
documentos
Assíncrona
A ausência de linha divisória vertical, entre os elementos da Tabela 4, indica que a
divisão entre os modelos e tipos de interação, em função do tipo de orientação do serviço Web
não é rígida. Ou seja, existem serviços Web classificados como orientados a RPC que
utilizam mensagens como modelo de interação, modelo de processamento centrado em
documento e tipo de interação assíncrona. O inverso também é possível. Dessa forma, a
Tabela 4 refere-se à maioria dos casos.
Os serviços Web centrados em objetos de negócio são caracterizados por uma série
de chamadas de métodos. Elas aplicam lógicas de negócio do serviço a um conjunto de
objetos de negócio que contêm informações requeridas para se processar a requisição. Um
bom exemplo de serviço Web centrado em objetos de negócio seria um serviço Web
desenvolvido para a autorização de cartão de crédito. Uma vez que este pode estar fazendo
uma chamada remota a um método que processa essa autorização com base nos detalhes do
cartão recebidos como parâmetro. O método invocado poderia ter a seguinte assinatura:
authorizeCreditCard(CreditCard cardDetails). Percebe-se que esta interação é mais bem
implementada com o modelo de interação por RPC e que o tipo de interação deve ser
síncrono, uma vez que o operador do sistema, com certeza está aguardando a resposta do
sistema remoto contendo a autorização ou rejeição do cartão. O Diagrama de Seqüência da
65
UML (Unified Modeling Language), mostrado na Figura 25 (SUN, 2002b) ilustra essa
interação.
Figura 25: Interação Síncrona de Serviço Web
No caso dos serviços Web centrados em documentos, a lógica do negócio se
encontra separada do conteúdo do documento. O serviço recebe um documento XML
contendo apenas dados, não explicitando uma ligação com regras de negócio diretamente. Em
outras palavras, métodos específicos não são invocados no serviço. Contudo, o serviço Web
aplica regras de negócio sobre o documento recebido e o conteúdo desse documento
determina o fluxo de processamento. Um serviço Web para agência de viagens é um bom
exemplo de serviço Web centrado em documento no qual o serviço recebe um documento
XML contendo detalhes de um itinerário de viagem desejado por um cliente (datas, lugares a
visitar acomodações preferidas, etc) e processa a requisição de acordo com o conteúdo do
documento. Neste caso, cabe a implementação do serviço Web com base no modelo de
interação por mensagens, cujo tipo de interação é assíncrono, pois o cliente da agência sabe
que sua solicitação ainda será analisada e que seu retorno virá mais tarde, por exemplo, por email.
66
3.5 A Arquitetura Global para Serviços Web em XML – GXA
Segundo DeMichilie (2002), em Abril de 2001 a Microsoft e a IBM submeteram
um artigo para um workshop sobre serviços Web organizado pelo W3C. Este trabalho,
intitulado “Web Service Framework”, define funções específicas que devem ser endereçadas à
construção de serviços Web destinados a suportar a integração aplicação-para-aplicação entre
organizações com diferentes infra-estruturas e relações de domínios confiáveis. Alguns dos
blocos de construção identificados pelo artigo incluem o seguinte:
•
Segurança – A habilidade de prover certas garantias sobre a origem e o
conteúdo de mensagens;
•
Transações – A habilidade de garantir a integridade de informações em
bancos de dados quando estas são acessadas por múltiplos serviços Web;
•
Coordenação – A habilidade de descrever e definir o fluxo de dados entre
múltiplos serviços Web;
•
Mensagem confiável – A habilidade de garantir que uma mensagem seja
recebida por seu recipiente de destino;
•
Roteamento e referência – A habilidade de especificar a rota de uma
mensagem; e
•
Anexos – A habilidade de incluir dados binários, em adição ao texto de
mensagens.
Desde que este artigo foi publicado, a Microsoft tem desenvolvido protocolos para
endereçar algumas áreas funcionais de serviços Web, algumas vezes com parceiros como a
IBM, a BEA e outras organizações que trabalham de forma independente. Assim nasceu a
GXA (Global XML Web Services Architecture) que é um conjunto de especificações
construídas sobre XML, que representam blocos de construção para a implementação de
serviços Web dotados das habilidades mencionadas anteriormente.
A arquitetura GXA passa pelas especificações do SOAP, WSDL e UDDI e está
dividida em três camadas conceituais comentadas a seguir:
•
Especificações Básicas de Serviços Web – Camada que envolve as
especificações SOAP, WSDL e UDDI de serviços Web;
•
Módulos SOAP – Conjunto de blocos de construção provido de maneira
que é inserido na pilha SOAP de forma a fornecer capacidade de integração
em baixo nível entre todos os consumidores do serviço Web. Esses blocos
67
podem ser utilizados individualmente ou em conjunto, garantindo a
uniformidade e consistência entre serviços Web; e
•
Infra-estrutura de protocolos – Trata-se de uma camada que provê
funcionalidade fim-a-fim. Esta camada é sensível à definição do hardware
que está executando. É esta camada que garante a serialização transacional
dos diferentes serviços Web.
A GXA apresenta a característica de ser modular, em que, por se tratar de uma
extensão da especificação SOAP, ela é capaz de prover funcionalidades monolíticas
uniformes fim-a-fim, que combinadas podem fornecer um conjunto de capacidades
padronizadas e reutilizáveis entre todos os serviços Web. Várias especificações estão sendo
propostas e dentre elas pode-se destacar: a WS-Coordination, a WS-Referral, a WS-Routing, a
WS-Security e a WS-Transaction. Essas especificações aliadas às especificações de base
aplicáveis a
serviços Web constituem a referida arquitetura. A Figura 26, baseada em
Demichillie (2002), ilustra a disposição dessas especificações na GXA.
Figura 26: A Arquitetura Global de Serviços Web em XML (GXA).
O elemento “...”, no grupo de especificações referentes a Módulos SOAP, indica
que novas especificações podem surgir. As duas especificações indicadas como “futuro”, na
camada de infra-estrutura de protocolos, encontram-se em fase de conclusão.
68
Esta arquitetura é de propósito geral, provendo infra-estrutura para múltiplos
propósitos como: B2B, B2C, soluções ponto-a-ponto, dentre outras, não requerendo
servidores centralizados ou a administração centralizada de processos.
No presente momento, a GXA é mais uma idéia do que uma realidade sobre a qual
companhias podem construir sistemas. Para torná-la realidade, a Microsoft e outros parceiros
terão de completar as especificações, adaptá-las a padrões e incorporá-las em seus produtos.
Nas próximas seções, são descritos os blocos de construção da GXA, apresentados
nesta seção.
3.5.1
Segurança em Serviços Web
O bloco de construção para prover segurança foi então definido como sendo a WS-
Security que inclui os seguintes aspectos:
•
Criptografia – Prevenindo que mensagens sejam lidas por partes não
autorizadas;
•
Autenticação – garantindo que a identificação de um remetente de
mensagens possa ser verificada; e
•
Assinatura digital – garantindo a integridade de uma mensagem desde o
tempo de seu envio até seu recebimento.
A WS-Security é uma especificação desenvolvida pela Microsoft, IBM e VeriSign,
que descreve como esses conceitos-chave de segurança podem ser implementados em
serviços Web e está disponível no pré-lançamento de um produto chamado WSDK (Web
Service Development Kit) lançado recentemente pela Microsoft que é um Add-on aplicável ao
Microsoft Visual Studio .NET que facilita a implementação de segurança em serviços Web.
Esta especificação descreve como tokens de segurança (credenciais de
autenticação e informações sobre um membro de um grupo de remetentes) são associados
com uma mensagem. Embora a WS-Security não requeira qualquer especificação de tipo de
token, ela descreve como codificar dois tipos de credenciais de segurança comuns:
certificados X.509 (o tipo de certificado digital usado para assinaturas digitais e criptografia
por autoridades de certificação pública como a VeriSign) e bilhetes Kerberos (usados para
autenticação no Windows e vários outros sistemas operacionais).
69
Além disso, para anexar credenciais, usuários de serviços Web necessitam de um
meio de criptografar o conteúdo de uma mensagem e assiná-la digitalmente para prevenir
interferências. Essas funções são descritas por duas especificações do W3C: XML-Encrypt e
XML-Signature respectivamente. WS-Security
descreve como aplicar essas funções de
criptografia e assinatura digital em mensagens SOAP.
3.5.2
Transações em Serviços Web
Uma transação é um método de coordenar um conjunto de operações em bancos de
dados visando garantir a integridade e consistência dos dados manipulados.
O processamento de uma venda, por exemplo, pode disparar processos
interdependentes de alteração de banco de dados como: registrar a venda, baixar estoque do
produto e debitar valor da venda do crédito do cliente. Este é um exemplo típico de transação
em que ou todas ou nenhuma operação deve ser processada a fim de se evitar inconsistências
e garantir a integridade do banco de dados.
A especificação que se dispõe a criar mecanismos que permitam a implementação
do conceito de transações em serviços Web, é a WS-Transaction, que foi desenvolvida pela
Microsoft, IBM e BEA e descreve como os serviços Web trabalham juntos para executar
transações.
3.5.3
Coordenação de Processos de Serviços Web
Linguagens de coordenação permitem a desenvolvedores descrever processos
complexos que envolvem coordenação de múltiplos serviços Web e define o fluxo de dados
entre eles. A Microsoft e a IBM definiram, cada uma, suas linguagens para coordenação:
XLANG e WSFL (Web Service Flow Language) respectivamente. Essas duas companhias,
juntamente com a BEA têm desenvolvido uma especificação unificada denominada
BPEL4WS (Business Process Execution Language for Web Services) que é a base para a
especificação WS-Coordination.
70
A WS-Coordination descreve um framework estensível para prover protocolos que
coordenam as ações de operações distribuídas. O framework definido nesta especificação
permite a um serviço de aplicação criar um contexto necessário para propagar uma atividade
para outros serviços e registrar protocolos de coordenação que operam em ambientes
heterogêneos.
Enquanto a Microsoft e a IBM suportam BPEL4WS, que ainda não é suportada
por outras empresas com diferentes abordagens, a Sun Microsystems, em parceria com a SAP,
desenvolveram a WSCI (Web Service Choreography Interface), e a Oracle tem consultado o
W3C para iniciar no desenvolvimento de seus padrões.
3.5.4
Mensagens Confiáveis entre Serviços Web
Muitos cenários de aplicações requerem algumas garantias de que uma mensagem
será entregue, mesmo se uma porção da comunicação estiver temporariamente indisponível.
Muitas corporações de tecnologia da informação já planejam utilizar produtos de fila como o
MSMQ (Microsoft Message Queuing) ou o IBM MQ Series para implementar essas
capacidades em suas aplicações internas. Mas esses produtos não interoperam através de
plataformas ou através de firewalls (sem configurações especializadas), não são padronizados,
e não são independentes de transporte.
Enquanto a IBM e a Microsoft reconhecem que necessitam endereçar mensagens
confiáveis, especificações ainda não foram disponibilizadas. Contudo, a Microsoft tem
desenvolvido um protocolo de mensagem confiável com base no SOAP, o SOAP Reliable
Message Protocol, na última versão do MSMQ.
3.5.5
Roteamento e Referência de Serviços Web
Os conceitos de roteamento e referência referem-se a como uma mensagem é
enviada de um local para outro, possivelmente através de um ou mais intermediários.
A WS-Routing é uma especificação desenvolvida pela Microsoft que descreve
como uma mensagem pode especificar que rota irá tomar. Outra especificação, a WS-Referral
71
foi construída sobre a WS-Routing e define um caminho para servidores para descobrir
dinamicamente quais intermediários estão presentes e que rotas estão disponíveis entre eles.
Além disso, a WS-Referral também pode ser usada para permitir a roteadores de serviços Web
executarem balanceamento de carga por meio da alternação entre servidores, dependendo de
quais têm recentemente enviado a referência de uma rota, indicando que eles estão
disponíveis.
Ambas as especificações, WS-Routing e WS-Referral são suportados pela
ferramenta WSDK, recentemente disponibilizada pela Microsoft.
3.5.6
Anexos em Mensagens de Serviços Web
Os serviços Web, por serem baseados em SOAP e XML, são fundamentalmente
baseados em tecnologias de texto. Enquanto a maioria dos dados que os usuários desejam
enviar (nomes de clientes, endereços, informações de compras, informações de projetos, etc)
são facilmente representadas em texto, algumas informações como imagens, áudio e vídeo,
são representadas na forma binária e devem ser transformadas para um formato texto, por
meio de um processo conhecido como “codificação Base64”, antes de serem enviadas via
SOAP. Ao chegar em seu destino, o texto é convertido novamente para apresentação binária
pelo processo inverso. Esta transformação aumenta o tempo de processamento para se enviar
e receber mensagens, bem como aumenta o tamanho da respectiva mensagem SOAP.
Se for possível anexar dados binários a mensagens SOAP, o processamento
adicional poderia ser evitado e o tamanho da mensagem seria reduzido significativamente. A
Microsoft desenvolveu o DIME (Direct Internet Message Encapsulation) e a especificação
WS-Attachment que descreve como encapsular dados binários numa mensagem e como anexar
essas mensagens binárias a uma mensagem SOAP, respectivamente. Em demonstrações, a
Microsoft mostrou que com DIME e WS-Attachments mais do dobro do número de imagens,
por segundo, podem ser transmitidas via serviços Web (DEMICHILLIE, 2002).
Embora DIME e WS-Attachment estão suportados no WSDK da Microsoft e têm
sido submetidos ao IETF (Internet Engineering Task Force) para possível padronização, eles
foram desenvolvidos pela Microsoft isoladamente. Outras organizações, como a IBM e
OASIS (Organization for Advancement of Structured Information Standard), não aderiram ao
suporte a DIME e WS-Attachment e estão perseguindo abordagens alternativas.
72
3.6 Desempenho de Serviços Web
Desempenho é um problema que ronda o universo dos sistemas distribuídos, e
conseqüentemente, dos serviços Web. O número de tecnologias e barreiras existentes entre os
provedores e consumidores, aliados às transformações e serializações das informações
existentes na execução de um serviço Web requer alguns cuidados e exige alguns esforços dos
desenvolvedores na construção de alguns mecanismos que visam amenizar o problema.
Foi encontrado em (SHIRAZI, 2003) uma lista interessante, contendo dicas e boas
práticas quanto à implementação de serviços Web. Esta lista foi elaborada com base em vários
documentos de diversos autores que afirmam que as melhores práticas no desenvolvimento de
serviços Web são principalmente as mesmas do desenvolvimento de sistemas distribuídos.
Requisitos de qualidade de serviços para serviços Web são, principalmente, os
seguintes:
•
Disponibilidade - Estar sempre pronto para ser invocado;
•
Acessibilidade - Poder executá-lo “agora”;
•
Integridade/Confiabilidade – Poder executar sem falhar;
•
Throughput – Taxa de execução por unidade de tempo;
•
Latência - Tempo de resposta a uma invocação;
•
Regularidade – A conformidade com padrões; e
•
Segurança – Aspectos envolvendo confidencialidade e autenticação.
O desempenho de serviços Web é diretamente afetado pelo seguintes fatores:
•
O tempo de resposta do servidor web e sua disponibilidade;
•
O tempo de execução de aplicações web (EJB/Servlets em servidores de
aplicação web, por exemplo);
•
O desempenho de Sistemas de Gerenciamento de Bancos de Dados e de
Sistemas Legados;
•
O desempenho da rede; e
•
O tipo de interação definido para o serviço Web (síncrona ou assíncrona).
No caso de serviços Web com modelo de interação baseado em RPC, o uso de
comunicações síncronas por meio de uma rede gera uma grande sobrecarga, indiferente do
protocolo que se está utilizando.
73
Com base nos fatores apresentados anteriormente, podem ser feitas algumas
considerações que visam amenizar o problema de latência dos serviços Web que geralmente é
mensurada em segundos. Uma forma de medir o desempenho de serviços Web é por meio da
adição de código, que registre o tempo transcorrido na execução do serviço.
Quando o transporte apresentar características como lentidão e/ou ausência de
garantias, ou o processamento for complexo e/ou demorado, é interessante considerar um
modelo assíncrono de mensagens, o que geralmente, conduz a serviços Web mais eficientes.
Na análise do desempenho dos serviços Web, é indicado considerar o desempenho
global do sistema. Não é recomendável realizar otimizações até conhecer onde estão os
gargalos do sistema, ou seja, não assuma que XMLs “inchados” ou limitações de HTTP são
um problema até que eles sejam demonstrados na prática.
Dependendo da freqüência e características comuns entre as mensagens, a
replicação de informações pode apresentar um ganho de desempenho considerável. As
repetidas chamadas de clientes SOAP, para acessar servidores, podem sufocar uma rede e
degradar o desempenho destes. O uso de cache de dados nos clientes, para evitar chamadas
ao servidor, pode amenizar o problema. Porém, é necessário garantir que as informações em
cache estejam atualizadas.
Vários esquemas de cache podem ser implementados, tanto no cliente quanto no
servidor, envolvendo cache de WSDL, resultados de chamadas já realizadas a serviços Web e
esquemas de definição, visando o aumento da escalabilidade. No caso de chamadas SOAP
transacionais é necessário realizar o cache do estado das sessões dos clientes.
A sobrecarga de SOAP inclui, principalmente, a extração do envelope SOAP e a
transformação da informação contida em XML. Muitos transformadores XML existentes
suportam verificação e conversão de tipos, verificação de boa formação, ou resolução de
ambigüidades, tornando-os mais lentos que ótimos. Nesse caso, sugere-se o uso de
transformadores XML mais simples, que executam somente as transformações essenciais.
Transformadores baseados em DOM (Document Object Model) são mais lentos que aqueles
baseados em SAX (Simple API for XML).
As solicitações deveriam ter balanceamento de carga, priorizada de acordo com o
valor do negócio que elas representam. Cuidados extremos dever ser tomados para garantir
que recursos não sejam travados por longos períodos de tempo, causando sérios problemas de
escalabilidade.
Na implementação de serviços, é recomendável utilizar tipos de dados simples no
SOAP como, por exemplo, string, int e float. Cada novo tipo de dado utilizado introduz um
74
serializador para converter o valor XML num valor da plataforma de desenvolvimento e viceversa, o que pode causar problemas de desempenho.
A utilização de equipamento de hardware melhores, maiores e mais rápidos,
principalmente nos provedores, é também uma forma de aumentar o desempenho dos serviços
Web. Mas existe um limite para a escalabilidade de um servidor. A maioria do desempenho
de aplicações não é escalável linearmente, com o aumento da capacidade do hardware.
Maiores detalhes sobre o desempenho de serviços Web podem ser obtidos a partir
de (SHIRAZI, 2003).
3.7 Conceitos no Desenvolvimento de Serviços Web
Como mencionado, a arquitetura básica de serviços Web, conta com três
componentes básicos: o divulgador de serviços, o provedor de serviços e o consumidor de
serviços.
Segundo Brittenhan (2001), cada um desses componentes básicos desempenha
atividades específicas para cada fase do ciclo de desenvolvimento de serviços Web que são
quatro: construção, instalação, execução e gerência.
Nas próximas seções são feitas considerações direcionadas apenas aos provedores
e consumidores de serviços Web. No caso dos divulgadores, não são feitas considerações
devido à sua atuação no processo de desenvolvimento de serviços Web ser passiva.
3.7.1
Fases do Ciclo de Desenvolvimento de Serviços
Web
Como dito na seção anterior, o ciclo de vida de desenvolvimento de serviços Web
possui quatro fases distintas que são ilustradas na Figura 27, construída a partir de Snell
(2002a) e Brittenhan (2001). Essas fases são descritas a seguir.
Construção (Build) – Esta fase envolve o desenvolvimento e testes da
implementação dos serviços, a definição da descrição de suas interfaces e a definição da
75
descrição de sua implementação. A implementação de serviços Web pode envolver o
seguinte:
•
A criação de um novo serviço Web e uma nova aplicação, o que envolve o
uso de linguagens de programação e modelos apropriados ao ambiente do
provedor do serviço;
•
A criação de um novo serviço Web a partir de uma aplicação existente, o
que envolve a geração de interfaces e empacotadores (wrappers) para
expor as funcionalidades desejadas; ou
•
A composição de um novo serviço Web a partir de outros serviços Web e
aplicações já existentes, o que envolve o sequenciamento e arranjo do fluxo
de mensagens entre programas de forma direta ou por meio de tecnologias
específicas. Os serviços Web
utilizados na composição podem existir
dentro e fora da empresa e são conhecidos como serviços de fluxo (service
flows).
Instalação (Deploy) – As atividades associadas a essa fase incluem a publicação
das interfaces e definição da implementação do serviço, instalação do código executável do
serviço e a eventual integração com sistemas legados.
Para serviços Web implementados para aplicações existentes, a instalação pode
incluir apenas o wrapper pois a aplicação já está instalada. Para serviços de fluxo, a instalação
inclui a customização do gerente de fluxo de trabalho e a execução e monitoramento de novos
fluxos por parte do gerente de processos de negócio. Integrações administrativas adicionais no
ambiente de execução devem ser executadas para a definição de operações baseadas em
autorização e credenciais de serviço e integração com sistemas legados.
Execução (Run) – Nesta fase, o serviço Web está totalmente instalado e
operando, sendo assim, os consumidores podem encontrar a definição desse serviço e invocar
suas operações. Funções de execução incluem ligações estáticas e dinâmicas, serviços de
interação como uma função de mensagens SOAP e interações com sistemas legados.
Gerenciamento (Management) – Esta fase envolve o gerenciamento e
administração de aplicações compostas de serviços Web. Aspectos como segurança,
disponibilidade, desempenho e qualidade do serviço (QoS) devem ser todos endereçados aqui.
76
Figura 27: Fases do Ciclo de Desenvolvimento de Serviços Web.
3.7.2
Abordagens para o Desenvolvimento de Serviços
Web
Esta seção descreve as abordagens utilizadas no ciclo de desenvolvimento de
serviços Web para os papéis de provedor e consumidor de serviços. Assume-se que o
divulgador já foi desenvolvido e se encontra disponível e operante, portanto não são
abordados aspectos de desenvolvimento referentes a este papel. A Tabela 5 fornece uma visão
geral dessas abordagens que consideram as fases de desenvolvimento comentadas
anteriormente, mais especificamente, as três primeiras: construção, instalação e execução.
Tabela 5: Abordagens para Desenvolvimento de Serviços Web.
Papel
Abordagem de Desenvolvimento
Divulgador
Nenhuma
Provedor
Green Field
Top Down
Bottom Up
Meet in the Middle
Consumidor
Static Binding
Build-time Dynamic Binding
Runtime Dynamic Binding
77
Segue uma descrição sumária para cada uma das abordagens (cenários) de
desenvolvimento de serviços Web, presentes na tabela anterior. Maiores detalhes podem ser
obtidos em Snell (2002a) e Brittenhan (2001).
Green Field – Neste cenário o desenvolvedor cria, não somente o serviço Web,
mas também a funcionalidade, em forma de aplicação, que será exposta como serviço na
Web.
Bottom Up – Esta abordagem segue a mesma linha da Green Field com a exceção
de que a funcionalidade a ser exposta pelo serviço Web já existe. Este é o cenário comum de
organizações cujos desenvolvedores estão trabalhando para migrar suas aplicações existentes
para a arquitetura de serviços Web.
Top Down – Esta abordagem é um pouco diferente. Ela inicia com a descrição de
interfaces de serviços Web existentes e trabalha para criar as funcionalidades de aplicação
capazes de implementar essas interfaces.
Meet in the middle – Este cenário é uma combinação dos cenários Bottom Up e
Top Down. Aqui, pode-se ter ambos, uma interface de serviço Web existente (WSDL
abstrata) e um código de aplicação existente (classe Java ou objeto COM, por exemplo), e
necessita-se utilizar ambos para se criar um serviço Web. Problemas podem surgir, contudo,
quando a interface abstrata existente não mapeia claramente várias operações expostas pelo
código de implementação. Neste caso deve-se criar uma ponte entre os dois.
Static Binding - A ligação estática é feita em tempo de construção para localizar a
definição da implementação de um serviço Web que será usado por um consumidor. A
definição de implementação do serviço contém uma referência para sua interface, que será
usada para gerar o código do service proxy. O service proxy contém uma implementação
completa da aplicação cliente que pode ser usada pelo consumidor para invocar operações do
serviço Web.
Buildtime Dynamic Binding - Esse tipo de ligação é usado quando um consumidor
de serviço deseja utilizar um tipo específico de Serviço Web, mas a implementação não é
conhecida até sua execução ou ele pode ser alterado em tempo de execução.
Runtime Dynamic Binding - Esse tipo de ligação é similar à ligação dinâmica em
tempo de construção. Uma interface de serviço é usada para gerar uma interface de service
proxy geral que pode ser usada para invocar qualquer implementação de interface de serviço.
Esse tipo de ligação é diferente uma vez que a interface do serviço é encontrada em tempo de
execução. Tendo encontrado a interface do serviço, o código Proxy é gerado, compilado e
então executado. Este tipo de ligação deveria ser, tipicamente, utilizada com uma interface de
78
usuário, porque não é possível para uma interação máquina-a-máquina ser realmente
dinâmica.
3.8 Plataformas de Desenvolvimento de Serviços Web
Atualmente, as duas principais plataformas de desenvolvimento de software que
dão suporte à implementação de serviços Web são a J2EE da Sun Microsystems e a .NET da
Microsoft. Elas provêm pacotes e recursos que viabilizam a implementação desse tipo de
aplicação e permitem a uma série de empresas desenvolverem ferramentas de auxílio aos
desenvolvedores. Empresas como Sun, IBM, Microsoft, Bea, Oracle e Iona estão
desenvolvendo e aperfeiçoando seus produtos, apostando no mercado de desenvolvimento de
serviços Web. Como dito, de um lado está a Microsoft com o Microsoft Visual Studio .NET,
e do outro se encontram as demais, que constroem ferramentas para suporte ao
desenvolvimento em J2EE como o WSAD – WebSphere Studio Application Developer da
IBM, o XMLBus da Iona e o JBuilder da Borland. Ferramentas desse tipo simplificam,
consideravelmente, a implementação de serviços Web. Elas apresentam uma série de
assistentes que facilitam a realização de várias atividades do processo de desenvolvimento de
serviços Web, expostas anteriormente.
O Microsoft .NET Framework apresenta um pacote denominado Services que
junto com outros de tratamento de documentos em XML compõem uma API para o
desenvolvimento de serviços Web. No caso da plataforma J2EE da Sun, podem ser
encontradas bibliotecas equivalentes no Java WSDP – Java Web Service Develop Pack.
Mas o suporte à criação de serviços Web vai além dessas tecnologias envolvendo
outras como servidores Web, servidores de aplicação e servidores SOAP.
A Tabela 6, construída com base em (VAWTER, 2001), apresenta de forma
sucinta, as principais tecnologias relacionadas às principais plataformas de desenvolvimento
de software que suportam a implementação serviços Web, no caso, Microsoft .NET e J2EE da
Sun.
79
Tabela 6: Tecnologias .NET e J2EE para Serviços Web
Item
.NET
J2EE
Plataforma Operacional
Windows
Windows, Unix, Linux, e outras
Linguagem de Programação
C#, VB.NET, C++ .NET
Java
CLR – Common Language
Interpretador
JVM – Java Virtual Machine
Runtime
Páginas HTML Dinâmicas
ASP.NET
Servlets/JSP – Java Server Pages
Integração
Host Integration Server
J2EE Connector – J2EE Connector
com
Sistemas
Legados
Architecture
Componentes
.NET Managed Components
EJB – Enterprise Java Beans
Serviços Web
SOAP, WSDL, UDDI
SOAP, WSDL, UDDI
Acesso a Bancos de Dados
ADO.NET
JDBC
–
Java
Data
Base
Connection
Vendedores de Middleware
Microsoft
Vários, aproximadamente 30.
3.9 Serviços Web na Plataforma J2EE
Implementar serviços Web em J2EE pode se tornar uma tarefa árdua, dependendo
da maneira como se aborda o desenvolvimento e principalmente, das ferramentas que se
utiliza. Isso é muito comum no desenvolvimento em Java, em que o desenvolvedor às vezes
não conhece todo o framework nem as ferramentas que podem lhe auxiliar, e acaba
desenvolvendo, às vezes de forma manual, funcionalidades que já foram implementadas e
estão prontas para serem utilizadas. Diante disso, é interessante analisar ferramentas de
auxílio à programação e selecionar aquela que melhor se adequa às necessidades do
desenvolvedor.
O número de tecnologias envolvidas na construção, instalação, execução e
gerenciamento de serviços Web é consideravelmente grande e cada uma delas apresenta suas
características e dificuldades de uso individuais. As várias tecnologias citadas nesta seção são
descritas nas seções posteriores.
Um serviço Web em Java pode ter sua implementação baseada numa classe
simples (Java Bean) ou até mesmo num EJB (Enterprise Java Beans). Em ambos os casos, o
desenvolvedor deverá se preocupar com detalhes de instalação da aplicação num contêiner
80
Web, provido por Servidores de Aplicação que ofereçam suporte a mensagens SOAP, como o
WebSphere da IBM, o Web Logic da Bea, o BES (Borland Enterprise Server) da Borland, e
soluções gratuitas como o Apache Tomcat em conjunto com o Servidor J2EE da Sun ou
JBOSS, por exemplo.
A Sun (SUN, 2002a) disponibiliza gratuitamente um pacote de ferramentas
intitulado JWSDP (Java Web Service Develop Pack) que é um conjunto de tecnologias que
visam simplificar e suportar o desenvolvimento e execução de serviços Web na plataforma
J2EE. Várias empresas fornecedoras de servidores de aplicação Web e ferramentas de
programação em Java estendem seus produtos, disponibilizando aos desenvolvedores de
software, uma série de assistentes que facilitam a utilização do JWSDP para o
desenvolvimento de serviços Web.
A Figura 28, reproduzida a partir de Vawter e Ronam (2001), ilustra as tecnologias
que constituem um ambiente de execução de serviços Web baseado em J2EE. A “camada
cliente” refere-se à porção consumidora e o “contêiner de serviços Web” mais os “sistemas
back-end” representam a porção provedora. Posteriormente, alguns desses elementos são
comentados nas subseções de 3.9.1 a 3.9.5.
Camada
Cliente
Parceiro de Negócios
ou outro sistema
Applets
Tecnologias de Web Services
(SOAP, UDDI, WSDL, ebXML)
IIOP
HTTP
HTTP
Firewall
Servlets
Java Server Pages
Java Beans/EJB
Conectores
Contêiner de serviços Web
Protocolo Proprietário
Repositório de
Contexto
Sistemas “Back-end”
SQL
Repositório
de
Banco
Contexto
de Dados
Sistemas Existentes
Sistemas Legados
ERP
(SOAP, UDDI, WSDL, ebXML)
Parceiros de Negócios
ou outro sistema
Figura 28: Ambiente de Execução de Serviços Web Baseado em J2EE
81
O “contêiner de serviços Web” representa, na verdade, os dois componentes
principais de um servidor de aplicações J2EE: o contêiner Web e contêiner EJB. O contêiner
Web suporta tecnologias como Java Beans, Servlets e Java Server Pages, enquanto o
contêiner EJB suporta componentes Enterprise Java Beans.
3.9.1
O Padrão ebXML
Hendricks et al. (2002), citam o ebXML como um padrão de indústria alternativo
ao UDDI. Porém, ambos apresentam diferenças quanto a seus escopos. O ebXML é uma
iniciativa cujo objetivo consiste em definir um escopo de padrões que indicam como o
comércio eletrônico é feito. O UDDI, entretanto, foi inicialmente criado por pessoas que
desejavam implementar registros de XML, mas que estavam insatisfeitas com o andamento
das atividades do ebXML. O escopo do UDDI não consegue definir todos os protocolos de
comércio eletrônico globais, ele se atém, pelo contrário, apenas aos registros XML.
Os registros XML baseados em UDDI são projetados para armazenar informações
básicas sobre o negócio e um índice de seus serviços Web. Os registros ebXML são
projetados para armazenar estas e outras informações adicionais relacionadas aos detalhes
comerciais, legais e logísticos de uma empresa. Portanto, o UDDI se destina a expor os
serviços Web oferecidos por uma empresa e como eles são usados, o ebXML se destina a
descrever o quadro geral: quem, o que, onde, porque e quando uma empresa resolve investir
em comércio eletrônico.
Aparentemente, os padrões ebXML e UDDI coexistirão durante algum tempo. Os
usuários de UDDI dizem que as empresas devem armazenar informações no UDDI Business
Registry Central e, em seguida, fazer referência a outra entrada num registro ebXML, caso
haja necessidade. Isso permite a interoperabilidade entre os dois padrões. Porém, esses
padrões estão sujeitos a constantes alterações, e o UDDI pode crescer em escopo e ser uma
alternativa para todos os provedores de ebXML. O ebXML pode superar o suporte existente
para UDDI e tornar-se o padrão dominante.
82
3.9.2
Servlets
Servlets são utilizadas para estender as capacidades de servidores que hospedam
aplicações acessadas via um modelo de programação solicitação-resposta (request-response).
Para tais aplicações a tecnologia Java Servlet define classes ServletHTTP específicas.
Os pacotes da linguagem Java, javax.servlet e javax.servlet.http, provêem
interfaces e classes para a implementação de servlets. Toda servlet deve implementar a
interface Servlet que define métodos do ciclo de vida desse tipo de classe.
Quando se implementa um serviço genérico, pode-se usar ou estender a classe
GenericServlet, provida pela interface de programação de aplicações Java Servlet. A classe
HttpServlet provê métodos como doGet e doPost para serviços HTTP específicos. Estes
métodos podem ser implementados para atender a solicitações ao servidor Web conforme o
método de requisição especificado na página HTML que invoca a Servlet, ou seja, GET ou
POST. Caso o desenvolvedor não especifique o método de requisição, o método GET é
executado. Uma Servlet é uma classe Java que pode ser invocada a partir de um navegador
Web. Dessa forma, ela pode instanciar objetos de outras classes Java hospedadas num
servidor e gerar, como saída, conteúdos dinâmicos em HTML.
No contexto de serviços Web, os Servlets podem ser utilizados para a
implementação de interfaces que podem ser acessadas pelos consumidores para testar o
serviço ou utilizá-lo efetivamente.
Maiores detalhes sobre essa tecnologia podem ser obtidos em Sun (2002a) e em
Hall (2001).
3.9.3
Java Server Pages
A tecnologia JSP - Java Server Pages também possibilita a criação de conteúdos
Web com componentes estáticos e dinâmicos. O desenvolvedor Web compõe documentos
baseados em texto contendo tags HTML, que correspondem à parte estática do documento
que será apresentada ao usuário da aplicação, e tags JSP que podem conter trechos de código
em Java, representando a porção dinâmica.
As tags JSP podem ser estendidas pelos desenvolvedores que podem implementar
tags customizadas a partir da tecnologia JSTL (JSP Standard Tag Library).
83
Pode-se dizer que a tecnologia JSP foi desenvolvida para tornar mais fácil e
produtiva a produção de Servlets, abstraindo do desenvolvedor Web algumas complexidades
dessa tecnologia. O uso da JSTL permite que os documentos desenvolvidos tenham um
número bastante reduzido de código Java, restringido-os à implementação das tags
customizadas.
O servidor Web que suporta JSP, processa o documento, que é um arquivo de
extensão “.jsp”,
e o converte internamente numa Servlet, em que a porção HTML do
documento, mais as tags customizadas são transcritas para código Java e a porção com código
Java é mantida.
Mais detalhes sobre as tecnologias JSP e JSTL podem ser obtidos em Sun (2002a)
e em Hall (2001).
3.9.4
Java Beans e Enterprise Java Beans
Como dito, na implementação de serviços Web, as regras de negócio podem ser
implementadas a partir de classes Java simples (Java Beans) ou de EJB (Enterprise Java
Beans).
Java Bean é uma classe de objetos que constitui um aplicativo Java e se este for
um aplicativo Web, essa classe é hospedada num contêiner Web, podendo ser instanciada a
partir de interfaces desenvolvidas em JSP.
Um EJB é, essencialmente, um componente que é criado com base num
framework de J2EE. Ele é controlado, e destruído num contêiner EJB que o hospeda. Esse
contêiner controla o número de componentes EJB existentes e os recursos que eles utilizam
como memória, conexões com bancos de dados e controle de transações, abstraindo do
desenvolvedor uma série de aspectos de implementação.
Um contêiner EJB é provido por um servidor de aplicações como o WebSphere
Application Server da IBM, o WebLogic da BEA, o BES da Borland, e o JBOSS da JBOSS
Group. Ele mantém um conjunto de instâncias de EJBs que estão prontas para serem
associadas a um cliente. Dessa forma, seu propósito primário é controlar e prover serviços
para os EJBs que ele mantém.
Os principais serviços oferecidos por um contêiner EJB são os seguintes:
84
•
Distribuição via proxies – O contêiner irá gerar um stub no lado cliente e um
skeleton no lado servidor, para o EJB. O stub e o skeleton irão utilizar RMI
sobre IIOP para comunicarem entre sí;
•
Gerenciamento do ciclo de vida do EJB – Criação do EJB, gerenciamento de
estados e destruição são controlados pelo contêiner, tudo o que o
desenvolvedor deve fazer é implementar os métodos apropriados;
•
Nomes e registro – O contêiner EJB e o servidor irão prover o EJB com
acesso a serviços de nomes. Esses serviços são utilizados por clientes locais e
remotos para encontrar o EJB e pelo próprio EJB para localizar recursos que
ele eventualmente necessite;
•
Gerenciamento de Transações – O contêiner EJB pode realizar o controle de
transações entre objetos permitindo operações de commit e rollback;
•
Segurança e Controle de Acesso – Diretivas de segurança provêem uma
forma do desenvolvedor facilmente delegar a aplicação de segurança no
contêiner;
•
Persistência – Caso seja do interesse do desenvolvedor, EJBs de entidade
podem ser gerenciados por mecanismos de persistência do contêiner. Estados
podem ser salvos e restaurados sem que o desenvolvedor edite uma única
linha de código.
Existem três tipos diferentes de EJBs que possuem finalidades distintas, a saber:
•
EJB de Sessão (Session Bean) – É utilizado para mapear fluxos de processos
de negócios. Existem dois sub-tipos de EJB de sessão: stateless e statefull. O
subtipo stateless trata cada invocação do cliente a um EJB como uma
conexão, já o statefull retém a conexão entre interações sucessivas do cliente;
•
EJB de Entidade (Entity Bean) – Esse tipo de EJB encapsula persistência de
dados num banco de dados, tipicamente uma linha parcial ou completa de
informação presente numa tabela de banco de dados. Ele provê serviços
automáticos que garantem que a visão orientada a objetos de um dado
persistente se mantenha sincronizada a todo instante, com o dado real
residente no banco de dados. Como exemplo pode-se citar uma tabela de
banco de dados com informações de clientes na qual cada registro mapeia
para uma instância de EJB de entidade;
85
•
EJB Dirigido a Mensagem (Message-Driven Bean) – São projetados para uso
em aplicações com requisitos de comunicação assíncrona consumidoras de
mensagens JMS (Java Messaging Services). Ao contrário de Sessions Beans
e Entity Beans eles não possuem interfaces publicadas, operando
anonimamente no modo stateless.
Pode-se afirmar que EJB é comumente utilizado no seguinte:
•
Em aplicações corporativas e Web, provendo a lógica de negócios que está
por trás da camada de apresentação, ou de interface do usuário implementada
com o uso de tecnologias como Servlets, JSP ou Java Swing (Interface
gráfica no padrão Windows). O uso de EJB nesse tipo de aplicação permite
um alto nível de escalabilidade e manutenibilidade;
•
Aplicações de comércio eletrônico do tipo business-to-business (B2B)
possibilitando a integração de sistemas; e
•
Aplicações de integração corporativa (EAI – Enterprise Application
Integration) em que diferentes sistemas existentes numa empresa podem ser
integrados.
O uso de EJB pode propiciar, principalmente, a abstração de detalhes complexos
de implementação bem como a separação das regras de negócio das interfaces com usuários e
acesso a dados. Isso se deve ao fato de seu projeto implementar um padrão de projeto de
software (Design Pattern) conhecido como MVC (Model View Controller).
Detalhes sobre EJBs, incluindo outras tecnologias J2EE, podem ser obtidos em
Bond (2002) e em Ahmed (2002).
3.9.5
Conectores J2EE
Conectores J2EE representam uma arquitetura que possibilita aos componentes
EJB interagirem com sistemas de informação corporativa (EIS -Enterprise Information
System) que incluem vários tipos de sistemas: ERP, processamento de transações em
mainframes e bancos de dados não relacionais.
86
A arquitetura J2EE Connector visa simplificar a integração de diversos EIS,
principalmente com aplicações legadas, não escritas em Java. Ela provê uma solução Java
para o problema de conectividade entre vários servidores de aplicação e EIS existentes.
Segundo a Sun, pelo uso da arquitetura J2EE Connector, desenvolvedores de EIS
não necessitam customizar seus produtos para cada Servidor de Aplicação, e fornecedores de
servidores que suportam conectores J2EE não necessitam adicionar códigos customizados
para adicionar conectividade para um novo EIS.
Detalhes sobre J2EE Connector podem ser obtidos a partir de Sun (2002c, 2002d).
3.10 Serviços Web na Plataforma Microsoft .NET
O principal objetivo dos serviços Web é prover a interoperabilidade entre
softwares desenvolvidos em tecnologias distintas, podendo estes, estarem dentro de uma
mesma organização ou em organizações diferentes. Dessa forma, as tecnologias e
padronizações de serviços Web oferecem uma série de mecanismos que possibilitam sistemas
heterogêneos trabalharem juntos. Contudo, sempre existem divergências entre as companhias
fornecedoras dessas tecnologias, pois cada uma, eventualmente aposta em produtos diferentes
para atender às especificações, chegando até mesmo a utilizar padrões alternativos.
Newcomer (2002) afirma que as diferenças entre as plataformas .NET e J2EE são
mais significativas do que as diferenças de suas abordagens para serviços Web. A filosofia
fundamental das plataformas permanece: se o desenvolvedor definiu que sua plataforma é
Windows e ele deseja se beneficiar das “facilidades” de uso e produtividade que as
ferramentas Microsoft oferecem, a melhor alternativa de tecnologia para desenvolvimento de
serviços Web com certeza é a .NET; mas se ele deseja, acima de tudo, independência de
plataforma operacional, ele deve considerar o uso de J2EE. De um lado J2EE oferece a
independência de plataforma operacional e do outro, a .NET oferece a independência de
linguagem, permitindo ao desenvolvedor utilizar linguagens de programação diferentes dentro
de um mesmo ambiente de desenvolvimento visual, que é o Microsoft Visual Studio .NET.
Pode-se afirmar que desenvolver serviços Web em .NET é consideravelmente mais
simples do que em J2EE, pois a ferramenta Microsoft Visual Studio .NET esconde uma série
de detalhes e oferece um conjunto muito eficiente de assistentes. Por outro lado, o controle do
desenvolvedor sobre o que foi implementado é bem menor. Os ambientes de auxílio ao
87
desenvolvimento de software em J2EE estão melhorando a cada dia, porém, ainda requerem
maior conhecimento técnico.
A Figura 29, reproduzida a partir de Vawter e Ronam (2001), ilustra as tecnologias
e padrões utilizados pela Microsoft para viabilizar serviços Web, e permite inclusive, fazer
uma comparação com o ambiente de execução de serviços Web baseado em J2EE,
apresentado na Figura 28. Na seqüência, são tecidos alguns comentários, sobre os detalhes
mais relevantes desse ambiente.
Camada
Cliente
Parceiro de Negócios
ou outro sistema
(SOAP, UDDI, WSDL, BizTalk)
Aplicações
Windows
Forms
HTTP
HTTP
Firewall
ASP .NET
.NET Managed Components
Host Integration server 2000
Conteiner de Serviços Web
Passport
.NET
SQL
Repositório
SQLdeServer
Contexto
2000
Sistemas
Mainframe
Parceiros de Negócios
ou outro sistema
Sistemas “Back-end”
Figura 29: Ambiente de Execução de Serviços Web Baseado na Arquitetura .NET
No caso da Microsoft, o contêiner de serviços Web é provido pelo IIS (Internet
Information Service), que desempenha o papel de servidor de aplicações Web.
Nota-se, na Figura 29, em relação à Figura 28, que dentro do contêiner de serviços
Web existem também, três camadas de tecnologias que se destinam, respectivamente, a
prover interfaces para o usuário, gerenciar componentes que implementam regras de negócio
e possibilitar a integração com sistemas legados e outras tecnologias.
ASP.NET é a alternativa Microsoft utilizada para a implementação de interfaces de
usuário em aplicações Web, concorrendo com Servlets e JSP da arquitetura J2EE. Os
88
Componentes Gerenciados .NET (.NET Managed Components) “corresponde” aos EJBs e a
tecnologia Host Integration Server 2000 se encarrega de fornecer meios de integrar a
aplicação, que se está desenvolvendo, a sistemas legados, sendo assim, “correspondente” ao
J2EE Connector.
A tecnologia Windows Forms representa a alternativa Microsoft às Applets e
Aplicações Swing Java, permitindo o desenvolvimento de softwares que podem ser
executados fora do ambiente Web.
Com relação à tecnologia de banco de dados, soluções baseadas em Microsoft
possuem facilidades de conexão ao SQL Server, porém, outros SGBDR podem ser utilizados.
O elemento “Passport .NET”, presente na camada de sistemas back-end, é no caso,
um serviço de autenticação, residente nos servidores da Microsoft, que pertencente ao produto
que ela batizou de Hailstorm. Trata-se de um conjunto de serviços Web, com propósitos
específicos, que podem ser utilizados como blocos de construção para a implementação de
aplicações, mediante sua contratação.
O BizTalk é uma iniciativa da Microsoft que oferece infra-estrutura e recursos
para troca de documentos de negócio, baseados em XML, por meio da Web. Ele também
propicia a integração de sistemas corporativos como por exemplo: ERPs, e-commerce, e
sistemas legados. Maiores detalhes sobre o BizTalk podem ser obtidos em Microsoft (2003a).
O HIS (Host Integration Server) 2000 é um produto da Microsoft que visa
facilitar a integração de sistemas desenvolvidos em plataformas diferentes incluindo
tecnologias relacionadas a sistemas legados hospedados em mainframes. Ele se dispõe a
prover integração em três níveis: aplicação; dados e rede. Informações mais detalhadas podem
ser obtidas em Microsoft (2003b).
Vawter e Ronam (2001) e Newcomer (2002) apresentam maiores detalhes, sob o
aspecto comparativo, do desenvolvimento de serviços Web utilizando J2EE e .NET.
3.11 Resumo do Capítulo e Resultados Obtidos
Neste capítulo foram apresentados os conceitos básicos e uma descrição das
especificações e tecnologias utilizadas na implementação, instalação, descoberta e invocação
de serviços Web.
89
Uma proposta de arquitetura de aplicativos orientados a serviço é mostrada em
detalhes seguida de algumas questões que representam desafios para o desenvolvimento de
serviços Web eficientes, como aspectos de transações, segurança e desempenho.
Foram apresentadas as abordagens e cenários, sobre os quais se desenvolve
serviços Web, mostrando aos desenvolvedores situados tanto na porção provedora quanto
consumidora, os diferentes pontos de partida para a criação, disponibilização e consumo
desses serviços. Esses pontos de partida são definidos em função da existência ou não, tanto
do serviço Web, quanto de sua implementação, por exemplo, um serviço Web pode ser criado
a partir de uma aplicação existente na organização, ou os dois podem ser concebidos juntos.
Para cada abordagem apresentada existe um conjunto de passos a serem seguidos,
envolvendo: a implementação da aplicação; a definição da interface do serviço; sua
publicação num servidor de registros; dentre outras.
Atualmente, as duas plataformas de desenvolvimento de software mais utilizadas
na implementação de serviços Web são J2EE (Java to Enterprise Edition) e Microsoft .NET.
Embora os princípios de serviços Web sejam aplicados da mesma forma nas duas, elas se
apóiam em ambientes de execução suportados por produtos distintos.
As informações sobre a tecnologia de serviços Web apresentadas neste capítulo
propiciam o entendimento de suas capacidades e algumas limitações, fornecendo também,
uma visão geral das tecnologias correlatas. Como pôde ser observado, a investigação de
serviços Web envolveu a pesquisa de diversos padrões e tecnologias relacionadas, como por
exemplo: Internet, Servidores de Aplicações Web, J2EE, .NET Framework, XML e SOAP.
Com base nisso, pode-se afirmar que os serviços Web são mais uma conseqüência da
existência de uma série de tecnologias do que algo totalmente inédito. Uma questão
importante está na utilização de XML e SOAP que propicia o acoplamento de componentes
de aplicações por meio da Internet.
Devido ao fato da tecnologia de serviços Web ser algo recente, pelo menos durante
a fase que foi dedicada à sua investigação, não se pôde obter um conjunto de literatura
satisfatório que oferecesse o suporte adequado. Disso decorreu o grande volume de obtenção
de informações oriundas da Internet e de artigos técnicos de empresas.
No próximo capítulo, os detalhes de uma proposta de solução para a
interoperabilidade de SGPs, são apresentados, bem como informações a respeito do processo
de desenvolvimento de software que foi utilizado para produzir, de forma sistemática, um
conjunto de artefatos que documentam essa solução.
90
4 Capítulo IV
Uma Proposta de Solução de
Interoperabilidade para a Gestão de Projetos
de Larga Escala Envolvendo Empresas
Parceiras
Este capítulo apresenta o processo de desenvolvimento de software utilizado para
se analisar o problema de interoperabilidade na gestão de projetos de larga escala envolvendo
empresas parceiras, especificar requisitos e propor um modelo de solução baseado na
interoperabilidade de software e uma proposta de solução baseada neste modelo e na
tecnologia de serviços Web.
Os resultados da aplicação do processo de desenvolvimento de software são
apresentados relatando a concepção de documentos que envolvem o seguinte: uma visão do
problema endereçado, dos envolvidos ou interessados, e de uma proposta de solução para o
mesmo; um plano de gerenciamento de requisitos dessa solução; e as estratégias e ferramentas
utilizadas para se especificar requisitos funcionais e não funcionais a serem contemplados na
solução e que se aplicam ao modelo de interoperabilidade proposto.
4.1 Utilização de um Processo de Desenvolvimento de
Software
O modelo de interoperabilidade para softwares de gestão de projetos é descrito na
Seção 4.2, porém, com o intuito de formalizar a concepção de uma proposta de solução
baseada neste modelo, principalmente em termos de documentação, fornecendo meios para a
deste trabalho em iniciativas futuras, foi selecionado e aplicado, um processo de
desenvolvimento de software.
Com base nas informações constantes em Kruchten (2000) e Quatrani (2000),
pode-se afirmar que o Processo Unificado Rational, em inglês, RUP (Rational Unified
91
Process), é um processo de desenvolvimento de software cuja finalidade é viabilizar o
sucesso de grandes projetos de software, reduzindo o impacto dos problemas comumente
encontrados. Ele possui em sua essência o resultado do trabalho de três metodologistas: Grady
Booch, Ivar Jacobson e James Rumbaugh. Como produto, ele é apresentado na forma de um
material de referência, no formato HTML, dotado de um mecanismo de busca e um vasto
conjunto de modelos de documentos (artefatos) que podem ser utilizados com editores de
texto, editores de páginas da Web, e softwares de gestão de projeto.
Além desses modelos de documentos existem também modelos de projetos e
tutoriais de ferramentas que podem ser utilizadas para auxiliar a execução do processo de
desenvolvimento de software. Fazem parte desse conjunto: ferramentas de apoio à gerência de
requisitos, modelagem visual e gerência de configuração e mudanças.
A aplicação do RUP independe da utilização específica das ferramentas citadas
anteriormente, ou seja, pode-se utilizar ferramentas de outros fornecedores para auxiliar a
execução das atividades sugeridas pelo processo.
Como citado por Kruchten (2000), o RUP implementa o que a Rational chama de
“As melhores práticas no desenvolvimento de software”, são as 6 (seis) seguintes:
•
Desenvolvimento Iterativo e Incremental – Refere-se à análise, projeto e
implementação incremental de subconjuntos do sistema no ciclo de vida do
projeto de software. A cada iteração, um conjunto de funcionalidades do
sistema é planejado, desenvolvido e testado, priorizando os pontos de maior
risco.
•
Gerenciamento de Requisitos – Assegura que se resolva o problema certo
construindo o sistema correto por meio de uma abordagem sistemática para
extrair, documentar e gerenciar os requisitos.
•
Uso
de
Arquiteturas
Baseadas
em
Componentes – Visa a
reusabilidade, manutenibilidade e extensibilidade dos diversos elementos que
compõem o sistema. Um componente combina dados e funções para atender
a um propósito específico, podendo ser desenvolvido ou adquirido de
terceiros.
•
Modelagem Visual utilizando a UML – Auxilia no gerenciamento da
complexidade do projeto de software provendo visualizações gráficas da
arquitetura do sistema. Serve também como mecanismo de comunicação
92
entre o cliente e a equipe de desenvolvimento do sistema e entre a própria
equipe de desenvolvimento.
•
Verificação Contínua da Qualidade - Visa garantir que os requisitos
sejam atendidos, à medida que se desenvolve iterativamente. Aliada ao
desenvolvimento
iterativo,
ela
permite
eliminar,
antecipadamente,
inconsistências entre requisitos, projeto e implementação.
•
Controle e Gerenciamento de Mudanças – Provê espaços de trabalho
seguros para cada desenvolvedor, integração automatizada, desenvolvimento
paralelo e gerenciamento de construção (build) do produto de software.
Possui seu foco em três pontos principais: a coordenação de atividades e
artefatos; a coordenação de iterações e releases; e o controle de mudanças no
software.
Quatrani (2000) e Kruchten (2000) apontam a estruturação do RUP ao longo de 2
(duas) dimensões, a saber:
•
Tempo – Divisão do ciclo de vida do projeto de desenvolvimento de
software em fases e iterações; e
•
Componentes do processo – produção de um conjunto específico de
artefatos pela execução de atividades bem definidas.
A estruturação do processo ao longo do tempo envolve a divisão do projeto de
software nas 4 (quatro) seguintes fases:
•
Iniciação – foco na especificação da visão do projeto;
•
Elaboração – foco no planejamento das atividades e recursos necessários,
especificando as características e projetando a arquitetura do software;
•
Construção – foco na implementação (codificação) dos elementos definidos
na arquitetura; e
•
Transição – foco na entrega e disponibilização do produto de software ao
cliente, envolvendo aspectos como implantação e treinamento.
A estruturação ao longo da dimensão de componentes do processo inclui as
seguintes 6 (seis) macro-atividades, conhecidas como disciplinas:
93
•
Modelagem de Negócios – Representa um conjunto de atividades voltadas
para o entendimento dos processos de negócio do cliente referentes ao
contexto em que se insere o produto do projeto de software para a
identificação das capacidades do sistema e necessidades dos usuários;
•
Requisitos – Representa um conjunto de atividades voltadas para a
elaboração da visão do produto do projeto de software juntamente com um
conjunto de requisitos funcionais e não funcionais do produto de software a
ser desenvolvido;
•
Análise e Design – Representa um conjunto de atividades voltadas para a
definição de uma descrição de “como” será realizada a implementação do
produto de software do projeto;
•
Implementação – Representa um conjunto de atividades voltadas para a
produção de códigos-fonte que resultarão num sistema executável;
•
Teste – Representa um conjunto de atividades voltadas para verificar se o
produto do projeto de software possui a qualidade esperada e atende aos
requisitos especificados; e
•
Implantação – Representa um conjunto de atividades voltadas para a
entrega e disponibilização do produto do projeto de software ao cliente.
As 6 (seis) disciplinas apresentadas anteriormente visam a produção do produto do
projeto de software. Mais três disciplinas são definidas oferecendo suporte a essa produção.
São elas:
•
Gerência de Configuração e Mudança – Representa um conjunto de
atividades voltadas ao gerenciamento de versão dos artefatos (documentos,
modelos e códigos-fonte, por exemplo), produzidos na execução das
disciplinas de produção, bem como ao gerenciamento do ambiente de
trabalho da equipe de desenvolvimento;
•
Gerência de Projeto – Representa um conjunto de atividades voltadas para
a gestão do projeto de software, tendo como base os conceitos descritos no
PMBOK (PMI, 2000); e
•
Ambiente – Representa um conjunto de atividades voltadas para a
personalização do RUP, definindo e aprimorando o processo de
desenvolvimento de software da organização que está desenvolvendo o
94
projeto de software, e a preparação do ambiente da mesma para suportar as
atividades que serão executadas numa determinada fase.
A Figura 30, extraída de Rational (2002b), oferece uma visão geral do processo,
mostrando também, a concentração de esforço relativo às disciplinas, que é variável, em cada
fase. Nota-se que nas primeiras iterações o foco é mais voltado para requisitos e nas iterações
finais a concentração se dá mais na implementação do produto de software.
Figura 30: Visão Geral do Processo Unificado Rational
O RUP foi desenvolvido para suportar grandes projetos de software, mas existe
uma versão para projetos pequenos que pode ser encontrada em sua documentação. Segundo a
Rational (2002b), quando se pretende utilizar o RUP, pela primeira vez, não é aconselhável
aplicá-lo diretamente a um projeto de software sem antes atentar para atividades da disciplina
de ambiente que sugerem a realização de personalizações necessárias, adequando-o à
realidade de quem o adota.
Maiores detalhes sobre este processo de desenvolvimento de software podem ser
obtidos no próprio produto (RATIONAL, 2002b) ou em Kruchten (2000) e Quatrani (2000).
Pode-se afirmar que, na elaboração deste trabalho, foi executada uma iteração
referente à fase de iniciação, tendo como maior foco, a disciplina de requisitos que, por
definição do processo, possui por finalidade:
95
•
Estabelecer e manter a concordância com os clientes e outros envolvidos
sobre o que o sistema, a ser desenvolvido, deverá fazer;
•
Oferecer aos desenvolvedores do sistema uma compreensão melhor dos
requisitos a serem atendidos;
•
Delimitar o sistema a ser desenvolvido;
•
Fornecer uma base para planejar o conteúdo técnico das iterações;
•
Fornecer uma base para se estimar o custo e o tempo de desenvolvimento do
sistema; e
•
Definir uma interface de usuário para o sistema a ser desenvolvido, focando
nas necessidades e metas dos usuários.
A execução das atividades da referida disciplina propiciou a produção dos
seguintes artefatos:
•
Documento de Visão que apresenta o problema endereçado, os stakeholders,
suas solicitações e a solução tecnológica proposta (Apêndice 1);
•
Glossário de termos técnicos utilizados na especificação dos requisitos
(Apêndice 2);
•
Plano proposto para o Gerenciamento dos Requisitos (Apêndice 3);
•
Documento contendo considerações e um levantamento preliminar de
requisitos funcionais (Casos de Uso) de serviços Web aplicáveis à gestão de
projetos envolvendo empresas parceiras (Apêndice 4);
•
Documento de Especificações Suplementares que representam um conjunto
de requisitos não funcionais para a solução, tais como desempenho e
usabilidade (Apêndice 5); e
•
Relação Analítica de Requisitos, emitida a partir da ferramenta utilizada para
o gerenciamento de requisitos (Rational RequisitePro), contendo todos
requisitos especificados para a solução tecnológica proposta, agrupados por
tipo de requisitos e acompanhados de seus atributos (Apêndice 6).
As próximas seções deste capítulo apresentam os resultados obtidos da aplicação
do RUP para a análise do problema endereçado neste trabalho e a proposta de uma solução.
96
4.2 Uma Visão do Problema e o Modelo de Solução
Proposto
Como foi citado no Capítulo II, o estabelecimento de parcerias para o
desenvolvimento de produtos ou serviços tem se tornado cada vez mais comum,
principalmente quando os riscos e os investimentos para o empreendimento são considerados
altos pelos envolvidos.
Com relação à gestão de projetos, quando duas ou mais empresas se juntam num
esforço comum, e cada uma é responsável por parte deste empreendimento, surge a
necessidade de integração dos processos e ferramentas de gestão, de forma a propiciar o
planejamento e o acompanhamento integrado do projeto como um todo.
As alternativas de software de gestão de projetos disponíveis crescem a cada dia e
até então, tem-se constatado que as soluções existentes se proõem a resolver o problema
primando pela centralização, como por exemplo, a solução implementada pela EMBRAER,
comentada na Seção 2.3.
A alternativa de solução proposta neste trabalho prima pela distribuição do
processamento e interoperabilidade dos softwares de gestão de projetos utilizados pelas partes
envolvidas, sejam eles cópias do mesmo produto ou produtos distintos. Em primeira instância
pensa-se na interoperabilide de softwares baseados na mesma metodologia de gestão de
projetos, porém, não se descarta a possibilidade de definição, em trabalhos futuros, de uma
estensão deste modelo que propicie a interoperabilidade de softwares baseados em
metodologias de gestão distintas.
O modelo de solução baseado em interoperabilidade parte do princípio de
definição e implementação, em softwares de gestão de projetos, de um conjunto componentes
e interfaces de software padronizadas que atendam aos requisitos funcionais, em sua maioria
referentes a funcionalidades da área de gestão de projetos, e não funcionais, geralmente
relacionados a aspectos como segurança, usabilidade e desempenho, que são mais
relacionados à implementação. Requisitos funcionais e não funcionais são apresentados nas
Seções 4.4 e 4.5.
A Figura 31 ilustra o modelo proposto no qual a idéia básica é que essas interfaces
possam ser acessadas remotamente para a troca e processamento de dados. Tais operações são
controladas pelos componentes que implementam estas interfaces, no caso os “Provedores de
Funcionalidades”. Além de prover interfaces e implementar mecanismos que controlam sua
utilização, sugere-se a implementação de componentes de acesso a estas mesmas interfaces,
97
no caso pelos componentes intitulados “Consumidores de Funcionalidades”, desta forma, um
determinado software de gestão de projetos pode interoperar com outra cópia ou outro
software desta mesma categoria, instalado em um local remoto, hora provendo, hora
consumindo funcionalidades.
Software de Gestão de Projetos
Software de Gestão de Projetos B
<<comunica>
Provedores de
Funcionalidades
Consumidores de
Funcionalidades
Interfaces
Funcionalidades de
Gestão de Projetos
Consumidores de
Funcionalidades
Funciona li dades de
Gestão de Projetos
<<comunica>
Provedores de
Funcionalidades
Interfaces
Figura 31: O Modelo de Interoperabilidade para Softwares de Gestão de Projetos.
A ativação da interoperabilidade pode ser realizada por meio de parâmetros de
configuração e por meio de dados de elementos de gerenciamento registrados nos softwares,
por exemplo, se ao definir elementos de um projeto o usuário associar empresas parceiras e
para estas existirem informações associadas que permitam o estabelecimento de comunicação
entre os softwares, estes estarão aptos a interoperar.
A tecnologia de serviços Web, descrita no Capítulo III, é uma alternativa para
implementação de uma solução baseada no modelo proposto. Diante disto, foi elaborada uma
instância de solução que a utiliza. Esta proposta de solução é descrita a seguir.
O documento de Visão (Apêndice 1) é proposto pelo RUP como um modelo para
se definir o problema, os stakeholders e uma proposta de solução. Nele, a definição do
problema é apresentada por meio do quadro abaixo:
98
O problema
ausência da interoperabilidade de softwares de gestão de
projetos, concebidos a partir de tecnologias distintas.
Afeta
empresas e organizações que desenvolvem projetos de larga
escala envolvendo empresas parceiras e contratadas.
O seu impacto é
existe um grande volume de retrabalho na execução das
atividades dos processos de gestão desses projetos, reduzindo
sua eficiência.
Uma boa solução seria
dotar os softwares de gestão de projetos de um conjunto de
serviços Web que os permita interoperar por meio da Internet
ou de uma intranet, trocando dados e realizando
processamentos.
Estes serviços Web são aplicações que residirão nas fronteiras das organizações,
propiciando a interoperabilidade de softwares concebidos a partir de tecnologias distintas e
que se encontram hospedados em locais remotos.
A Figura 32 fornece uma visão geral da solução proposta, nomeada como
“Serviços Web para a Gestão de Projetos” (Web Services for Project Management - WS4PM).
A idéia básica é que SGPs, dotados de porções provedoras e consumidoras de WS4PM,
representem potenciais nós de um sistema distribuído de fraco acoplamento que propicie o
gerenciamento de projetos relacionados, de forma integrada.
Figura 32: WS4PM – Serviços Web para a Gestão de Projetos.
A Figura 32 ilustra um cenário em que um determinado usuário do “Software de
Gestão de Projetos B”, instalado numa Empresa Parceira de Projeto, ao registrar uma dada
informação, dispara uma “aplicação consumidora” que acessa remotamente um serviço Web
99
provido pelo “Software de Gestão de Projetos A”, instalado na Empresa Líder do Projeto.
Esse serviço processa as informações, e se for o caso, retorna resultados à Empresa Parceira
do Projeto. O inverso pode ocorrer para alguns casos, em que o “Software de Gestão de
Projetos A” consume serviços providos pelo “Software de Gestão de Projetos B”.
Como citado na Seção 4.1, atividades da disciplina de requisitos do RUP foram
executadas para especificar requisitos da solução proposta. A Figura 33 exibe a estratégia
utilizada para a especificação dos requisitos funcionais e não funcionais referentes aos
WS4PM.
Figura 33: Estratégia Utilizada para Especificação de Requisitos dos WS4PM.
No Apêndice 6 constam vários requisitos, porém merecem destaque 74 (setenta e
quatro), sendo 54 (cinqüenta e quatro) funcionais (identificados com o prefixo UC) e 20
(vinte) não funcionais (identificados com o prefixo SS). Eles são o resultado do detalhamento
de requisitos mais abstratos, como os identificados com os prefixos STRQ e FEAT, e
representam, respectivamente, o quê a solução tecnológica deve propiciar aos usuários e
algumas características desejáveis.
A especificação dos requisitos funcionais é comentada na Seção 4.4 e a
especificação dos requisitos não funcionais é comentada na Seção 4.5.
Um dos requisitos funcionais foi selecionado, e para este, foram executadas as
atividades pertencentes às disciplinas de análise e design, implementação e testes obtendo
como resultado os protótipos de software de gestão de projetos que são comentados e
detalhados no Capítulo V.
100
4.3 Um Plano para o Gerenciamento de Requisitos
Segundo o RUP (RATIONAL, 2002), o Plano de Gerenciamento de Requisitos é
um artefato da disciplina de requisitos que é desenvolvido pelo analista de sistemas na fase de
Iniciação e atualizado
nas fases subseqüentes. Sua finalidade é descrever como serão
configurados os documentos de requisitos, os tipos de requisitos e seus respectivos atributos e
rastreabilidade. Esses quatro elementos formam a base de sustentação da referida disciplina
considerando o seguinte:
•
os documentos de requisitos são definidos para se conhecer quais
documentos terão em seu conteúdo textos contendo requisitos;
•
os tipos de requisitos ajudam na organização e classificação dos requisitos,
os
atributos
auxiliam
na
qualificação,
quantificação,
controle
e
gerenciamento dos requisitos; e
•
a rastreabilidade auxilia o entendimento da origem dos requisitos e o impacto
dos mesmos no sistema em desenvolvimento.
Além disso, esse plano descreve a organização (empresa que está desenvolvendo o
projeto de software), as responsabilidades e interfaces externas, as ferramentas a serem
utilizadas, o ambiente e a infra-estrutura necessária para se realizar a gerência de requisitos.
Com base nas informações contidas nesse plano configura-se a ferramenta que será
utilizada para auxiliar a gerência de requisitos definindo os elementos básicos citados
anteriormente.
Para o gerenciamento dos requisitos de WS4PM desenvolveu-se um plano desse
tipo, como mostra o Apêndice 3, que pode ser reaproveitado em trabalhos futuros. A Figura
34 ilustra a rastreabilidade de requisitos da solução WS4PM, presente nesse plano,
envolvendo os seguintes tipos de requisitos:
•
STRQ (Stakeholder Request) – solicitações dos stakeholders;
•
FEAT (Feature) – características ou recursos da solução;
•
UC (Use Case) – casos de uso (requisitos funcionais); e
•
SS (Supplementary Specification) – especificações suplementares (requisitos
não funcionais).
101
Figura 34: Rastreabilidade de Requisitos dos WS4PM.
As solicitações dos envolvidos e interessados (STRQ) são descritas em alto nível,
e representam, de forma bastante resumida, o que deve ser endereçado pelos WS4PM a fim de
atender as expectativas dos stakeholders. Elas foram definidas a partir do documento de Visão
e são rastreadas para as características (FEAT).
As características (FEAT) são definidas a partir do detalhamento de itens de
solicitações de envolvidos e interessados (STRQ) e a partir de outros requisitos, alguns deles
constantes no documento de Visão. Esses recursos são rastreados para casos de uso (UC) e
para especificações suplementares (SS). Uma característica (FEAT) pode ser rastreada a partir
de zero ou mais casos de uso (UC), ou a partir de zero ou mais especificações suplementares
(SS).
Os casos de uso (UC) são os requisitos da solução que possivelmente serão
implementados e representam algo de valor observável aos usuários.
As especificações suplementares (SS) são os requisitos não funcionais dos
WS4PM que deverão ser observados e atendidos no ato da implementação.
4.4 Especificação de Requisitos Funcionais
Os WS4PM devem ser implementados de forma a atender requisitos funcionais de
interoperabilidade para a gestão de projetos que envolvem empresas parceiras.
Partindo desse princípio, entrevistas e uma pesquisa de campo, foi realizada na
Empresa Brasileira de Aeronáutica S/A. – EMBRAER, possibilitando a elaboração de um
documento contendo considerações e um levantamento preliminar de requisitos de
interoperabilidade entre parceiros de projeto, representando as solicitações dos principais
envolvidos.
102
Foram apontados pela gerência do programa EMBRAER-170/190, seis pontos
críticos na gestão dos projetos, explicitando a necessidade da integração dos processos de
planejamento e controle envolvendo gestão de requisitos, gestão de configuração e mudanças,
gestão de riscos, gestão de custos e gestão da comunicação. Essas premissas e os
conhecimentos contidos no PMBOK (PMI, 2000) conduziram a elaboração do referido
documento.
Foi elaborado um conjunto de fichas que reúnem considerações e um levantamento
preliminar de requisitos de serviços que visam a interoperabilidade entre parceiros de
projetos. Esses requisitos foram validados pelo Program Officer da EMBRAER e
posteriormente analisados e classificados. As fichas elaboradas possuem a seguinte estrutura:
•
Um identificador;
•
O nome do processo da gestão de projetos;
•
A área de conhecimento, da gestão de projetos, a que ele se relaciona (entre
parênteses);
•
Uma breve descrição do processo;
•
Uma lista dos processos de seu grupo, sobre os quais sua execução interfere
diretamente; e
•
As eventuais considerações e requisitos identificados.
Às considerações e requisitos foram atribuídos identificadores, no intuito de
facilitar análises posteriores.
A Tabela 7, além de propiciar uma visão da abrangência das considerações e
requisitos de interoperabilidade especificados, exibe a ordem de apresentação e os
identificadores atribuídos aos processos.
Os identificadores nas fichas apresentam uma sintaxe baseada na Tabela 7, por
exemplo: Ca1.1 é um identificador que representa uma Consideração apontada no grupo de
processos “a” (Iniciação), processo “1” (Iniciação) cujo contador é 1. Um exemplo de
requisito é Rb1.3 que representa um requisito identificado no grupo de processos “b”
(Planejamento), no processo “1” (Definição das Atividades), cujo contador é 3.
Na
Figura 35 apresenta-se uma das fichas elaboradas, para exemplificar o que foi explicado
anteriormente.
103
Tabela 7: Abrangência das Considerações e Requisitos de Interoperabilidade entre Parceiros de Projetos.
ID
a
a1
b
b1
b2
b3
b4
b5
b6
b7
b8
b9
b10
b11
b12
b13
b14
b15
b16
b17
b18
b19
b20
b21
c
c1
c2
c3
c4
c5
c6
c7
d
d1
d2
d3
d4
d5
d6
d7
d8
e
e1
e2
Processo da Gestão de Projeto
Processos de Iniciação
Processo de Iniciação
Processos de Planejamento
Planejamento do Escopo
Detalhamento do Escopo
Definição das Atividades
Sequenciamento das Atividades
Estimativa de Duração das Atividades
Desenvolvimento do Cronograma
Planejamento da Gestão de Riscos
Planejamento dos Recursos
Estimativa dos Custos
Orçamentação dos Custos
Desenvolvimento do Plano do Projeto
Planejamento da Qualidade
Planejamento Organizacional
Montagem da Equipe
Planejamento da Comunicação
Identificação dos Riscos
Análise Qualitativa dos Riscos
Análise Quantitativa dos Riscos
Planejamento de Resposta a Riscos
Planejamento de Aquisições
Preparação das Aquisições
Processos de Execução
Execução do Plano do Projeto
Garantia da Qualidade
Desenvolvimento da Equipe
Distribuição das Informações
Pedido de Propostas
Seleção de Fornecedores
Administração de Contratos
Processos de Controle
Relato de Desempenho
Controle Integrado de Mudanças
Verificação do Escopo
Controle de Mudanças do Escopo
Controle do Cronograma
Controle dos Custos
Controle da Qualidade
Controle e Monitoração de Riscos
Processos de Encerramento
Encerramento de Contratos
Encerramento Administrativo
Área de Conhecimento
Gestão do Escopo
Gestão de Escopo
Gestão de Escopo
Gestão de Prazo
Gestão de Prazo
Gestão de Prazo
Gestão de Prazo
Gestão de Riscos
Gestão de Custos
Gestão de Custos
Gestão de Custos
Gestão da Integração
Gestão da Qualidade
Gestão de RH
Gestão de RH
Gestão da Comunicação
Gestão de Riscos
Gestão de Riscos
Gestão de Riscos
Gestão de Riscos
Gestão de Aquisição
Gestão de RH
Gestão de Escopo
Gestão de Escopo
Gestão de Prazo
Gestão de Custos
Gestão de Riscos
104
d1) Relato de desempenho (Gestão da Comunicação)
É a coleta e divulgação de informações de desempenho do projeto incluindo relatórios de
status, medidas de progresso, e novas estimativas do projeto.
Processos do seu grupo sobre os quais interfere diretamente: d2.
Cd1.1 – Relatórios de situação (posição com relação ao cronograma e ao orçamento),
progresso (percentual de atividades realizadas, em andamento versus completadas) e
previsões (predizem o futuro do projeto em termos de situação e andamento) podem ser
enviadas de forma automática.
Cd1.2 – O valor das variáveis utilizadas nas análises de variação, tendências e valor agregado
podem ser encaminhados das Empresas Parceiras para a Empresa Líder do Projeto, para que
esta consolide as informações e consiga fazer a Análise de Valor Agregado para projeto como
um todo.
Rd1.1 – Podem ser necessários serviços que permitam à Empresa Líder do Projeto obter
dados de relatórios de situação, progresso e previsões gerados pelas Empresas Parceiras.
Rd1.2 – Podem ser necessários serviços que automaticamente, ou não, enviem dados
referentes a análises de tendência, variação e valor agregado, das Empresas Parceiras para a
Líder do Projeto.
Rd1.3 – Podem ser necessários serviços que permitam o registro de requisições de mudanças,
mediante a análise de desempenho do projeto.
Figura 35 : Exemplo de Ficha Contendo Considerações e Levantamento Inicial de Requisitos.
O documento, contendo as fichas citadas anteriormente, foi importado para a
ferramenta de auxílio à gerência de requisitos, Rational RequisitePro, que foi configurada
conforme informações constantes no Apêndice 3 (Plano de Gerenciamento de Requisitos).
Ferramentas como o RequisitePro geralmente implementam uma forma de gerenciamento de
requisitos baseada em tipos de documentos, tipos de requisitos e atributos, permitindo a
execução de consultas e emissão de relatórios, como o apresentado no Apêndice 6 (Relação
Analítica de Requisitos).
105
4.5 Especificação de Requisitos Não Funcionais
Os requisitos não funcionais são aqueles referentes a métricas de software, como
por exemplo: usabilidade, confiabilidade, desempenho, suportabilidade, restrições de projeto
(design) e padrões aplicáveis. Detalhes sobre essas métricas podem ser obtidos em (GRADY,
1992). Além dessas métricas, algumas funcionalidades comuns a vários casos de uso são
incluídas nesse conjunto.
Pode-se citar como exemplos de requisitos não funcionais a
necessidade de se implementar um controle de transações e a especificação de um tempo
limite de resposta para um determinado processamento, ou seja, requisitos que não agregam
valor direto ao negócio do usuário e que são oriundos de necessidades como segurança,
observação a padrões e qualidade do software como produto e como processo.
Os requisitos funcionais somados aos requisitos não funcionais formam o conjunto
completo de requisitos que um determinado software deve atender. O RUP prevê um artefato
para coletar os requisitos não funcionais, também conhecidos como Especificações
Suplementares.
Foram especificados alguns requisitos não funcionais para os WS4PM que
constam no Apêndice 5 (Especificações Suplementares) e, por conseqüência da execução de
atividades da disciplina de requisitos do RUP, no Apêndice 6 (Relação Analítica de
Requisitos). Esses requisitos foram coletados a partir de entrevistas com os stakeholders e a
partir de algumas especificações oriundas, principalmente, do W3C e do WS-I que são
consórcios formados por empresas e profissionais que atuam na definição de padrões
aplicáveis ao desenvolvimento de serviços Web. Vale salientar que esta especificação
apresenta alguns valores para determinados requisitos, como por exemplo, os de desempenho,
que ainda necessitam de validações.
Este capítulo apresentou detalhes sobre as atividades realizadas para a análise e
proposta de uma solução para a interoperabilidade entre softwares de gestão de projetos
utilizados no gerenciamento de projetos de larga escala envolvendo empresas parceiras.
A solução proposta sugere a implementação de serviços Web em softwares de
gestão de projetos de forma que cada empresa possa publicar aqueles que lhe convém,
permitindo que seu software de gestão de projetos interopere com os softwares de gestão de
106
projetos de suas empresas parceiras, independente da tecnologia a partir da qual eles foram
concebidos e da distância geográfica existente entre elas.
A utilização do RUP, como processo para desenvolvimento de software,
formalizou e estruturou a concepção da solução tecnológica, por meio da execução de
atividades e utilização de modelos de artefatos pré-definidos.
Por meio de investigações sobre definições dos processos de gestão de projetos
contidas no PMBOK (PMI, 2000), e de entrevistas realizadas com a equipe do Programa
EMBRAER 170/190, que desenvolve projetos de aeronaves contando com a participação de
vários parceiros, foi possível especificar e validar um conjunto de requisitos funcionais que
representam funcionalidades a serem expostas como serviços Web, auxiliando a gestão de
projetos desse tipo.
Investigações sobre organizações que desenvolvem especificações para serviços
Web, como a W3C e a WS-I, permitiram o levantamento de algumas especificações
suplementares para os WS4PM, que representam requisitos não funcionais referentes a
aspectos de qualidade de software como usabilidade, confiabilidade e desempenho.
A especificação de requisitos funcionais, apresentada na Seção 4.4, tentando
abranger as nove áreas de conhecimento da gestão de projetos é, de certa forma volumosa,
pois o número de processos e conseqüentemente, de funcionalidades inerentes, é grande.
Porém, acredita-se ter especificado um conjunto inicial de requisitos de interoperabilidade
para a gestão de projetos de larga escala envolvendo empresas parceiras, que pode ser
refinado e estendido.
O plano de gerenciamento de requisitos elaborado define a forma como os
requisitos da solução proposta podem ser especificados e gerenciados ao longo de todo o
processo de seu desenvolvimento. Este plano foi utilizado para configurar a ferramenta
auxílio ao gerenciamento de requisitos RequisitePro, propiciando a qualificação e
quantificação dos requisitos especificados, bem como a emissão de uma Relação Analítica de
Requisitos que se encontra no Apêndice 6.
No próximo capítulo apresenta-se os detalhes da implementação de dois protótipos
de SGP dotados de WS4PM, desenvolvendo um estudo de caso que propicia a verificação,
validação e teste tanto da solução proposta quanto da tecnologia de serviços Web, apresentada
no Capítulo III.
107
5 Capítulo V
Protótipos de Software de Gestão de Projetos
Interoperáveis
Neste capítulo apresenta-se a finalidade, as características, os principais detalhes
da implementação, o cenário de testes e as tecnologias utilizadas na construção de dois
protótipos de software de gestão de projetos que representam produtos de fabricantes
distintos, dotados de WS4PM. Estes softwares interoperam, trocando e processando dados de
gerenciamento de projetos relacionados, propiciando a verificação, teste e validação do
modelo de solução e da tecnologia proposta neste trabalho.
Inicialmente são apresentadas a finalidade e as características dos protótipos
incluindo os casos de uso implementados. Na seqüência, são apresentadas e comentadas as
interfaces de usuário, os detalhes da arquitetura de software, projetada de forma a suportar a
exposição de funcionalidades como serviços Web, os detalhes da implementação de
programas que representam os serviços e seus consumidores, e por fim, o cenário de testes
que propiciou desenvolver um estudo de caso referente à análise de valor agregado
envolvendo projetos relacionados, por meio da interoperabilidade de softwares de gestão de
projetos.
5.1 Finalidade e Características dos Protótipos
Um dos requisitos funcionais (casos de uso), resultantes do trabalho relatado no
Capítulo IV, foi selecionado e dois protótipos de software de gestão de projetos foram
desenvolvidos a partir de tecnologias distintas para testar e validar a proposta de
interoperabilidade entre softwares de gestão de projetos e a viabilidade da utilização da
tecnologia de serviços Web como alternativa para sua implementação. Sendo assim, um dos
protótipos foi desenvolvido na plataforma J2EE e o outro na plataforma .NET permitindo o
108
desenvolvimento de um estudo de caso que envolve o planejamento e acompanhamento
integrado de projetos relacionados, utilizando a técnica de Análise de Valor Agregado.
O software desenvolvido na plataforma J2EE é um Aplicativo Web, ou seja, ele é
instalado num servidor e suas interfaces de usuário são acessadas via Internet ou intranet com
o uso de navegadores Web, como o Internet Explorer e o Netscape. Este aplicativo foi
batizado com o nome JavaPMSWeb e está dotado de serviços Web que propiciam a
interoperabilidade com outras cópias suas e com outros softwares desenvolvidos a partir de
outras tecnologias.
Dentre as funcionalidades implementadas no JavaPMSWeb, destacam-se as
seguintes:
•
O cadastro de empresas parceiras de projetos da empresa usuária do
software, que podem representar para ela, tanto líderes de projetos quanto
parceiras de projeto;
•
A definição de projetos, em termos de Project Charter, permitindo sua
eventual associação a projetos de uma empresa parceira. Neste caso, o
projeto em questão refere-se ao projeto de um componente do produto de um
projeto de larga escala cuja empresa parceira especificada é a líder;
•
A definição do escopo de projetos, por meio de WBS, permitindo a eventual
associação de seus elementos a projetos de empresas parceiras. Neste caso, o
projeto em questão refere-se a um projeto de larga escala cuja empresa
usuária do software é a líder e delega o elemento de WBS a uma empresa
parceira de projeto;
•
A definição de um conjunto de datas de status nas quais ocorrem relatos de
desempenho para os elementos da WBS do projeto;
•
O lançamento de valores, possibilitando o planejamento e acompanhamento
do desempenho de elementos da WBS e, conseqüentemente, de projetos
como um todo; e
•
A visualização de relatórios que propiciam a Análise de Valor Agregado de
elementos da WBS e, conseqüentemente, do projeto como um todo.
A Rational (2002b) sugere que o comportamento de um sistema em
desenvolvimento seja documentado num “Modelo de Caso de Uso” que ilustra suas
109
funcionalidades (casos de uso), aquilo que o cerca (atores) e os relacionamentos entre os casos
de uso e os atores (diagramas de casos de uso).
Em Quatrani (2000) define-se caso de uso como uma seqüência de transações
executadas por um sistema que resulta em algo de valor observável para um ator. Um ator,
por sua vez, é alguém (usuário) ou alguma coisa (dispositivo ou outro sistema, por exemplo)
que interage com o sistema.
A Figura 36 exibe um Diagrama de Casos de Uso da UML, que exibe as principais
funcionalidades implementadas no protótipo JavaPMSWeb e os eventuais atores que podem
interagir com ele. A UML sugere a representação de casos de uso por meio de figuras em
forma de elipse e atores por meio de figuras em forma de boneco.
Manter Dados de Parceira
Equipe de Gestão de Aquisições
Associar Projeto a WBS de
Projeto de Parceira
<<usa>>
<<comunica>>
Definir Projeto
<<usa>>
Equipe de Gestão de Escopo
Definir WBS
Associar Elemento de WBS a
Projeto de Parceira
<<comunica>>
Software de Gestão de Projeto de Parceira
<<comunica>>
Análise de Valor Obtido
Equipe de Gestão de Prazos
Equipe de Gestão de Custos
Planejar e Relatar Desempenho de
Projeto
Equipe Funcional
Figura 36: JavaPMSWeb - Diagrama de Casos de Uso.
O caso de uso Planejar e Relatar Desempenho de Projeto, em destaque no
diagrama da Figura 36, é implementado no protótipo JavaPMSWeb contemplando o caso de
uso UC49, da solução WS4PM, especificado no Apêndice 6.
110
Para representar um software baseado em tecnologia distinta, foi desenvolvido na
plataforma Microsoft .NET, o JPMSClient. Trata-se de uma Aplicação de Formulário
Windows (Windows Form Application), diferente do JavaPMSWeb, que não pode ser
acessada por meio da Internet ou de uma intranet utilizando navegadores Web. No caso deste
protótipo, foi implementado um formulário simples que permite a manutenção de registros de
relato de desempenho por meio da invocação do respectivo serviço Web implementado no
JavaPMSWeb.
Como a principal finalidade dos protótipos é mostrar a viabilidade da
interoperabilidade entre softwares de gestão de projetos distintos ou não, por meio da
tecnologia de serviços Web, eles foram desenvolvidos com as seguintes limitações:
•
Não foram implementadas funcionalidades relacionadas à autenticação de
usuários e políticas de autorização;
•
Não foram implementados aspectos de segurança na comunicação como
criptografia e chaves de segurança;
•
Na invocação de serviços Web não foram implementados mecanismos de
controle de transação distribuída; e
•
O JPMSClient, desenvolvido na plataforma Microsoft .NET, é uma
aplicação do tipo Windows Form que apenas consume serviços Web do
JavaPMSWeb, exemplificando a independência de plataforma propiciada
pela utilização dessa tecnologia.
Vale lembrar que, embora os protótipos tenham sido implementados com as
limitações citadas acima, a tecnologia de serviços Web dispõe de recursos que permitem sua
implementação sem essas limitações, como visto no Capítulo III.
5.2 Principais Interfaces de Usuário
Esta seção apresenta, de forma sucinta, as principais interfaces de usuário
implementadas nos protótipos de software de gestão de projetos.
Como dito, o JavaPMSWeb é um aplicativo Web que pode ser acessado na
Internet ou numa intranet utilizando-se navegadores Web. Dessa forma, não é exigida a
instalação da aplicação nas máquinas clientes, pois as interfaces são construídas
dinamicamente em HTML e servidas ao usuário por meio de um servidor de aplicações Web.
111
A interface de usuário mostrada na Figura 37 representa a tela inicial do aplicativo
contendo um menu com as opções Home, Basics e Projects que permitem, respectivamente,
voltar a esta tela inicial, executar rotinas de cadastros básicos para o sistema (dados da
empresa usuária do sistema e de suas parceiras de projetos) e executar a manutenção de
projetos (planejamento e controle).
Figura 37: JavaPMSWeb - Interface de Usuário Principal.
Com relação aos cadastros básicos do sistema, o mais relevante é o Cadastro de
Parcerias, a partir do qual a empresa usuária do sistema pode efetuar a manutenção de
informações sobre suas empresas parceiras de projetos e dos WS4PM que elas dispõem. A
interface que provê esta funcionalidade pode ser acessada selecionando a opção Basics e em
seguida Partnerships. Ela é dividida em duas partes: uma contendo um formulário para
edição de dados, ilustrada na Figura 38, e outra contendo uma lista das parcerias cadastradas,
permitindo a manutenção de informações, conforme ilustrado pela Figura 39. O formulário de
edição de dados permite, por padrão, a inserção de registros de parceiras.
Os campos em destaque na Figura 38 representam um conjunto mínimo de
informações para acesso aos WS4PM da empresa parceira e validação do consumidor desses
serviços. O campo Service URL é onde se registra o ponto de acesso (endereço Web) aos
112
WS4PM da parceira, Service URI é o campo onde se informa o qualificador desses serviços
e Our ID in that Company é o campo que propicia o registro de um código de identificação
da empresa usuária do sistema junto à empresa parceira de projetos.
Figura 38: JavaPMSWeb - Edição de Dados de Empresas Parceiras.
Selecionando a opção Projects e em seguida Maintenance, o JavaPMSWeb
exibe uma interface que permite ao usuário definir ou efetuar manutenção em dados de
projetos, conforme ilustrado na Figura 40. No caso da manutenção, o usuário deve selecionar,
a partir de uma lista de projetos existentes, aquele que ele pretende efetuar a manutenção,
podendo editar sua definição ou realizar seu planejamento e controle.
Uma vez selecionada a opção de criação de um novo projeto (
descrição de um projeto existente (
) ou edição da
), a interface ilustrada na Figura 41 é exibida e o
usuário pode proceder com a digitação dos dados. Vale salientar que o conjunto de campos
em destaque, identificados como Link Elements to Other Eventual Project representam um
conjunto mínimo de informações necessárias para se estabelecer o relacionamento do projeto
em questão com outro projeto existente numa empresa parceira. Nesse caso, o projeto que se
está definindo refere-se ao projeto de um componente do produto de um projeto de larga
escala cuja empresa parceira, selecionada no campo Project Owner, é a mandatária. Os
113
projetos que não possuem um Project Owner especificado apresentam o conteúdo padrão
(This Enterprise) indicando que a empresa mandatária é a empresa usuária do sistema.
Figura 39: JavaPMSWeb - Manutenção de Registros de Empresas Parceiras.
Figura 40: JavaPMSWeb - Acesso à Definição ou Manutenção de Projetos.
114
Caso seja atribuído um Project Owner para um projeto, os campos Parent
Project ID, Parent WBS Item ID, Parent WBS Item Start e Parent WBS Item Duration
requerem, respectivamente, a digitação, do código de identificação do Projeto de Larga Escala
da empresa parceira, do código de identificação do elemento da WBS desse projeto, da
unidade de tempo em que se iniciam as atividades referentes ao elemento da WBS
especificado e a duração total, em unidades de tempo, das atividades referentes a este mesmo
elemento da WBS. Tais informações são necessárias para se estabelecer o relacionamento
entre os projetos.
A partir desse relacionamento, todas as informações de relato de desempenho
registradas para os elementos da WBS do projeto em questão são atualizadas, via WS4PM, no
elemento da WBS do projeto relacionado.
Figura 41: JavaPMSWeb - Definição de Projeto.
Caso o usuário selecione a opção de planejamento e controle de um determinado
projeto, da interface mostrada na Figura 40 (
), o JavaPMSWeb exibe a interface ilustrada
115
na Figura 42, permitindo a definição/visualização de sua WBS. Quando um elemento é
selecionado na árvore que representa a WBS, suas informações são exibidas no formulário à
direita e as operações de edição (
o elemento selecionado (
), exclusão (
), definição de novo elemento filho para
), e informação de Relatos de Desempenho (
) podem ser
executadas.
Foram implementadas algumas regras que definem quais operações podem ser
executadas em quais circunstâncias, por exemplo, não se pode definir elementos filhos para
um elemento da WBS que foi delegado a uma empresa parceira de projeto. Para delegar um
elemento da WBS a uma empresa parceira basta selecionar uma na caixa de seleção
Assigned to e digitar, na caixa de texto Related Project ID on the Partner, o código de
identificação do projeto da parceira que se refere ao item em questão. Caso o elemento da
WBS seja de responsabilidade da empresa usuária do sistema apenas a caixa a seleção
Assigned to é exibida contendo a informação (This Enterprise).
Figura 42: JavaPMSWeb - Definição da WBS de Projeto.
Quando o usuário seleciona a opção Performance, ele pode informar relatos de
desempenho, para o elemento da WBS selecionado à esquerda, a partir do formulário
ilustrado na Figura 43. Este formulário apresenta uma caixa de seleção contendo as datas de
116
status, em unidades de tempo definidas para o projeto, que exigem a informação de
Planejamento (PV – Planned Value) e de relatos de desempenho (EV – Earned Value e AC –
Actual Cost). Nesse caso, são exibidas apenas as datas de status que incidem dentro do
período de execução das atividades referentes ao elemento da WBS selecionado e que ainda
não possuem registro de planejamento ou de relato de desempenho informado. Ao registrar
uma informação para uma data de controle selecionada, esta é exibida na listagem constante
na parte inferior do formulário. A unidade monetária definida para o projeto também é
exibida.
A partir da listagem de planejamento e de relatos de desempenho existentes, o
usuário pode editar (
) ou excluir (
) um registro.
Caso o elemento da WBS selecionado seja um elemento delegado a uma empresa
parceira de projeto, as operações de manutenção de registros não são permitidas, pois ficam a
cargo da empresa parceira, que por meio de seu software de gestão de projetos invocará o
WS4PM de relato de desempenho que fará a manutenção de informações necessárias.
Quando um relato de desempenho é registrado para um elemento da WBS, seu
valor incide indiretamente no desempenho de seus elementos pai e, conseqüentemente, no
projeto como um todo.
O valor a ser informado no campo EarnedValue, apresentado na Figura 43,
refere-se ao resultado da aplicação de qualquer um dos métodos de obtenção do valor
agregado existentes, como por exemplo, aqueles propostos por Flemming e Koppelman
(2000).
O gráfico localizado à direita da interface (Earned Value Analisys), entre o
formulário de edição de dados e a listagem de relatos de desempenho existentes, conforme
ilustrado na Figura 43, permite a visualização da Análise de Valor Agregado para o elemento
da WBS selecionado.
Ao solicitar a visualização da Análise de Valor Agregado, para o elemento da
WBS selecionado, o sistema exibe a interface ilustrada na Figura 44, mostrando um gráfico
com os elementos básicos da referida técnica (PV – Valor Planejado, EV - Valor Agregado e
AC - Custo Real).
Logo abaixo do gráfico plotado são exibidas as respectivas informações textuais e
outras variáveis da técnica, agrupadas em três tabelas:
•
Uma contendo os valores informados pelo usuário (Current Values) e
acumulados (Cumulative Values) em cada data de controle;
117
•
Uma contendo as variações (Variance) e os índices de desempenho
(Performance Index) calculados com base nos valores acumulados; e
•
Uma última contendo as variáveis de estimativas para conclusão (To
Complete).
A Figura 45, a Figura 46 e a Figura 47 ilustram, juntas, o restante dessa interface.
Informações sobre a técnica de Análise de Valor Agregado, bem como sobre suas variáveis,
podem ser obtidas na Seção 2.1.5.
Figura 43: JavaPMSWeb - Planejamento e Relatos de Desempenho.
118
Figura 44: JavaPMSWeb - Gráfico da Análise de Valor Agregado.
Figura 45: JavaPMSWeb - Análise de Valor Agregado - Valores Correntes e Acumulados.
119
Figura 46: JavaPMSWeb - Análise de Valor Agregado - Variações e Índices de Desempenho.
Figura 47: JavaPMSWeb - Análise de Valor Agregado – Estimativas para Conclusão.
Além do JavaPMSWeb foi desenvolvido um outro protótipo com a tecnologia
Microsoft .NET que foi batizado com o nome JPMSClient. Trata-se apenas de uma interface
de usuário que consome o WS4PM de relato de desempenho, provido pelo JavaPMSWeb. A
120
Figura 48 exibe essa interface que permite a digitação de parâmetros necessários à invocação
do referido serviço Web. Ela é subdividida em três partes as quais uma solicita a digitação de
informações que são utilizadas na validação da transação (Link Elements to Project
Owner), outra solicita a digitação dos valores que são reportados (Performance Report) e
uma última (Action) contendo botões para a invocação de métodos (rotinas) do referido
WS4PM. O valor de retorno deste serviço Web é uma mensagem texto que é exibida na caixa
de texto intitulada “Result from Performance Report Web Service on JavaPMSWeb
Application”.
Alguns campos não são requeridos para operações de exclusão e estes são
devidamente identificados com o rótulo “(Not Required for Delete Operation)”.
Figura 48: JPMSClient - Interface do Software que Interopera com o JavaPMSWeb.
5.3 Detalhes da Arquitetura
O protótipo JavaPMSWeb teve sua arquitetura projetada com base nas
orientações presentes em Costa (2002) e em Quatrani (2000).
A Figura 49 ilustra, num alto nível de abstração, a arquitetura do JavaPMSWeb,
que é constituída de 5 (cinco) camadas, as quais cada uma desempenha um papel específico.
121
Essas camadas são representadas pelos pacotes com a identificação (estereótipo)
“<<layer>>”. São elas:
•
persistence – É a camada de acesso a dados. Ela abriga implementações
que visam facilitar a leitura e gravação de informações em arquivos XML e
em SGBDR (Sistema de Gerenciamento de Banco de Dados Relacional).
Essas implementações se apóiam em middlewares fornecidos por terceiros;
•
business – É a camada de entidades de negócio. Nela estão as
implementações que representam as entidades relacionadas ao contexto do
software;
•
control – É a camada de controle de fluxos de casos de uso. Nela estão as
implementações dos requisitos funcionais do software (casos de uso) que são
acessadas por meio das interfaces de usuário;
•
services – É a camada de serviços de software. Nela estão as
implementações de serviços que são expostos como serviços Web,
propiciando a interoperabilidade com outros softwares; e
•
presentation – É a camada de apresentação do software. Nela estão as
implementações de interfaces que propiciam sua interação de usuários com o
software.
Os usuários do sistema conseguem acessar apenas os elementos das camadas
presentation e services. Os elementos dessas duas camadas acessam elementos da camada
control que implementa as funcionalidades do software acessando, devidamente, elementos
da camada business que, quando necessitam efetuar operações de leitura e gravação de
dados, acessam elementos da camada persistence.
O pacote util é o único que não possui o estereótipo <<layer>>. Ele abriga
algumas classes utilitárias que são instanciadas nas diversas camadas do software. Dentre
essas classes, a mais significativa é uma classe denominada ExceptionControl que
implementa uma estratégia de controle de exceções do software (erros de execução), na qual a
codificação para tratamento de erros de processamento, nas camadas superiores, é
simplificada. Em determinados casos, as mensagens de erro com conteúdo muito técnico são
gravadas num arquivo (jmpserror.log) e são traduzidas para as camadas superiores ocultando
detalhes técnicos. Dessa forma, o usuário final recebe mensagens mais inteligíveis em seu
nível.
122
<<layer>>
presentation
<<layer>>
services
<<layer>>
control
<<layer>>
business
util
<<layer>>
persistence
Figura 49: JavaPMSWeb - Camadas do Software.
Cada camada do JavaPMSWeb é brevemente comentada nas próximas seções,
apresentando também, diagramas da UML. São utilizadas 5 (cinco) formas de notação da
UML para classes de software que auxiliam na visualização da arquitetura do sistema. São
elas:
•
Classe de Fronteira (
) – Notação para classe que implementa
interfaces de usuário;
•
Classe de Controle (
) – Notação para classe que implementa os fluxos
de eventos de casos de uso e controle de visualizações;
•
Classe de Entidade (
de negócio;
)– Notação para classe que implementa entidades
123
•
Classe de Serviço (
) – Notação para classes que implementa
Serviço de Software; e
•
5.3.1
Classe Padrão (
) – Notação padrão para outras finalidades.
A Camada de Acesso a Dados (persistence)
O pacote persistence representa a camada de acesso a banco de dados do
JavaPMSWeb, abrigando classes responsáveis pela leitura e gravação de informações em
tecnologias de armazenamento de dados, como arquivos XML e SGBDR. Apenas três
seguintes classes pertencem a ele:
•
DataAccess – Classe de objetos que utiliza o middleware JDBC da Sun,
implementando funcionalidades responsáveis pela leitura e gravação de
informações em SGBDRs. Métodos dessa classe recebem sentenças SQL
montadas na camada de entidades de negócio e as processa.
•
ConnectionPool - Classe de objeto que implementa um “arcabouço” de
conexões de usuários com o banco de dados, propiciando o reaproveitamento
de conexões já estabelecidas e conseqüentemente, contribuindo para o
aumento do desempenho do software. Instâncias dessa classe são criadas,
sempre que necessário, e armazenadas no servidor da aplicação de forma que
os objetos DataAccess, sempre que precisam acessar a base de dados,
obtêm uma dessas instâncias, a utiliza e devolve ao servidor. Se devido a
uma eventual concorrência de usuários do software, não existir uma conexão
disponível, uma nova é criada e disponibilizada. Componentes como este
podem ser obtidos de terceiros e reutilizados, além disso, alguns servidores
de aplicação, como o Apache Tomcat,
possuem esse serviço que pode
simplesmente ser utilizado; e
•
XMLReader – Classe de objetos que efetuam a leitura de um arquivo, no
formato XML, que contém dados de configuração do software, como por
exemplo, dados para a conexão do JavaPMSWeb com SGBDRs.
A Figura 50 apresenta um Diagrama de Classes da UML, mostrando as três classes
definidas e o relacionamento entre elas.
124
DataAccess
XMLReader
-connectionPool
Connecti onPool
Figura 50: JavaPMSWeb - Diagrama de Classes da Camada de Acesso a Dados.
A estratégia de utilização de um arquivo de configuração em XML
(jpmsconf.xml), aliada à arquitetura em camadas, provê uma certa independência de SGBDR
ao JavaPMSWeb permitindo a utilização de qualquer Banco de Dados Relacional, suportado
pela tecnologia JDBC (Java Data Base Conection), para persistir as informações. O
JavaPMSWeb foi testado com os SGBDRs MySQL, SQLServer e Oracle, e a troca de
SGBDR exigiu apenas a edição do arquivo de configuração. Além disso, vale salientar que o
baixo acoplamento mencionado, só foi possível, pois além do arquivo de configuração,
utilizou-se a linguagem de acesso a banco de dados SQL (Structured Query Language) em
sua forma padrão, conhecida como ANSI, e não foram utilizados recursos internos desses
produtos como gatilhos (triggers) e procedimentos armazenados (stored procedures).
O referido arquivo de configuração possui a seguinte estrutura, ilustrada,
seqüencialmente, da Figura 51 à Figura 54.
Figura 51: JavaPMSWeb - Elemento Raiz do Arquivo XML de Configuração do Software.
O elemento raiz denominado CONFIGURATION possui um elemento filho
denominado DATABASE. Além desse elemento podem ser definidos vários outros, que por
ventura, se fizerem necessários.
125
Figura 52: JavaPMSWeb - Elemento Raiz da Porção de Configuração de Acesso a Dados.
O elemento DATABASE possui elementos referentes a cada SGBDR suportado
pelo software desenvolvido (Oracle, SQLServer, MySQL, outros).
Figura 53: JavaPMSWeb - Elemento de Configuração de um SGBDR Específico.
126
Para cada elemento referente a um SGBDR, são definidos elementos que
representam itens de configuração. Como cada SGBDR eventualmente retorna códigos de
erro distintos para, por exemplo, operações ilegais e erros de dispositivo, o elemento
ERRORMAP envolve um conjunto de elementos ERROR que fazem o mapeamento de
códigos de erro retornados pelo SGBDR (DBCODE) para códigos de erro definidos na
implementação do JavaPMSWeb (SYSTEMCODE).
Figura 54: JavaPMSWeb - Elemento de Configuração de Mapeamento de Códigos de Erro.
5.3.2
A Camada de Entidades de Negócio (business)
O pacote business representa a camada de entidades de negócio envolvendo
classes que implementam entidades pertencentes ao contexto do software. Esta camada
agrupa as seguintes classes que são mapeadas para tabelas de bancos de dados:
•
Enterprise – Representa a empresa usuária do software;
•
Partner – Representa empresas parceiras de projetos da empresa usuária
do software;
•
Project – Representa projetos da empresa usuária do software;
•
WBSItem – Representa elementos da WBS de projetos da empresa usuária
do software;
•
Performance – Representa relatos de desempenho para elementos da
WBS de projetos da empresa usuária do software;
•
LinkToWBS – Classe de objetos que propiciam o relacionamento de
projetos, que estão sendo desenvolvidos pela empresa usuária do software,
com elementos da WBS de projetos de empresas parceiras; e
127
•
LinkToProject – Classe de objetos que propiciam o relacionamento de
elementos da WBS de projetos, que estão sendo desenvolvidos pela
empresa usuária do software, com projetos de empresas parceiras.
A Figura 55 exibe um Diagrama de Classes dessa camada do JavaPMSWeb.
Apenas os atributos das classes Partner, LinkToWBS e LinkToProject são apresentados,
pois são os mais relevantes no contexto do protótipo desenvolvido, sendo os responsáveis
pelo relacionamento entre projetos de empresas parceiras.
Os atributos sSQL e isLoaded são utilizados, respectivamente, para montagem de
sentenças SQL e para verificar se os valores dos atributos da classe foram carregados da
respectiva tabela do SGBDR.
-linkToWBS
1
1
Project
Enterpris e
LinkToWBS
1
-project
Performance
0..n
parentPrjId
parentWbiId
parentWbiStart
parentWbiDuration
sSQL
isLoaded
1
-projectOwner
-perform ance
-partner
0..n
-WBSItem
1
1
-WBS
1..n
1
0..n
-childs
WBSItem
0..1
-parent
-linkToProject
1
0..n
Partner
id
name
details
responsible
serviceURL
serviceURI
ourIdThere
sSQL
isLoaded
LinkToProject
partnerPrjId
sSQL
isLoaded
Figura 55: JavaPMSWeb - Diagrama de Classes da Camada de Entidades de Negócio.
128
Objetos da classe Project possuem um conjunto (agregação) de itens (WBSItem)
que constituem sua WBS. Caso uma instância de Project se relacione com um projeto de
larga escala de uma empresa parceira de projeto, o atributo linkToWBS, dessa classe, é um
objeto não nulo que possui as seguintes informações:
•
parentPrjId - Identificador do Projeto de Larga Escala registrado no
software utilizado pela empresa mandatária do projeto (Project Owner);
•
parentWbiId - Identificador do elemento da WBS do projeto referenciado no
atributo anterior;
•
parentWbiStart – Data, em unidades de tempo (dia, semana ou mês), de
início das atividades, registrada no software utilizado pela Project Owner,
para o elemento da WBS identificado no atributo anterior;
•
parentWbiDuration – Duração total das atividades, em unidades de tempo
(dia, semana ou mês), registrada no software utilizado pela Project Owner,
para o elemento da WBS identificado no atributo parentWbiId;
•
projectOwner – Este atributo é resultado do relacionamento da classe
LinkToWBS com a classe Partner permitindo conhecer a empresa parceira
de projeto que é mandatária do projeto identificado em parentPrjId.
Caso um determinado elemento da WBS seja delegado a uma empresa parceira de
projeto, o atributo linkToProject, da classe WBSItem, é um objeto não nulo que possui
informações mínimas para relacionar o referido elemento ao projeto da parceira. Essas
informações são as seguintes:
•
partnerPrjId - Identificador do projeto registrado no software utilizado pela
empresa parceira de projeto; e
•
partner – Este atributo é resultado do relacionamento da classe
LinkToProject com a classe Partner permitindo conhecer a empresa
parceira de projeto responsável pelo desenvolvimento do elemento em
questão.
Tais informações poderiam ser obtidas por meio da invocação de serviços WS4PM
específicos, providos pela Project Owner e pela Project Partner.
No caso da classe Partner os atributos definidos para propiciar a
interoperabilidade são as seguintes:
129
•
serviceURL – Refere-se à URL do Servidor de Aplicações Web de
empresas parceiras de projetos a partir do qual é possível invocar os
WS4PM.
Um
exemplo
desse
endereço
http://www.mypartner.com/services/servlet/rpcrouter.
A
seria
palavra
rpcrouter representa uma Servlet que se encarrega de receber as invocações
de serviços Web, instanciar a classe de software que o implementa e executar
a funcionalidade desejada.
•
serviceURI – URI de identificação dos WS4PM, providos pelas empresas
parceiras de projetos da empresa usuária do software, propiciando
identificadores únicos para esses serviços;
•
OurIdThere – Utilizado para implementar um mecanismo simples de
autenticação. Refere-se ao identificador da empresa usuária do software junto
às suas empresas parceiras de projetos.
Objetos da classe WBSItem podem conter um conjunto de objetos da classe
Performance, e cada um deles, representa um relato de desempenho para um determinado
elemento da WBS do projeto. Um objeto WBSItem possui um atributo denominado parent,
que é uma referência a outro objeto WBSItem, permitindo conhecer o elemento pai de um
determinado item da WBS. Por outro lado, existe também um atributo denominado childs que
é uma referência para um conjunto de elementos filhos.
5.3.3
A Camada de Controle de Fluxos de Casos de Uso
(control)
Segundo o RUP (RATIONAL, 2002b), na especificação de requisitos de um
sistema a ser desenvolvido, os casos de uso são descritos detalhando seus fluxos de eventos
básicos, fluxos de eventos alternativos, pontos de extensão, pré e pós-condições para sua
execução.
Esta camada do software envolve as implementações desses fluxos levando em
consideração seus pontos de extensão e suas pré e pós-condições. Dessa forma, são definidas
unidades de programas (classes) para implementar cada caso de uso constante no diagrama da
Figura 36.
130
A estratégia consiste em prover as funcionalidades do software a partir dessas
classes, ou seja, toda interação deve ser propiciada por interfaces que acessam apenas os
elementos dessa camada. Estes por sua vez, se encarregam de acessar, “devidamente”, os
elementos da camada de entidades de negócio, que quando necessário, contam com o auxílio
de elementos da camada de acesso a dados para efetuar operações de leitura e escrita de
informações.
Um dos resultados da definição dessa camada é a possíbilidade de se implementar
vários tipos de interfaces de usuário (gráficas ou baseadas em texto, por exemplo) para prover
acesso a uma mesma funcionalidade do software.
A Figura 56 apresenta um Diagrama de Classes da UML que utiliza uma notação
específica para classes de controle. O intuito deste diagrama é apenas apresentar as classes
que implementam os casos de uso especificados.
Em tempo de análise e design pode ser elaborado um Diagrama de Classes para
cada caso de uso ilustrando o relacionamento da classe de controle, que o implementa, com as
classes de entidades de negócio. As classes de controle constantes no diagrama da Figura 56
são:
•
MaintainPartnershipControl – Classe que implementa o caso de uso
Manter Dados de Parceira;
•
ProjectDefinitionControl – Classe que implementa o caso de uso Definir
Projeto;
•
LinkProjectToWBSControl – Classe que implementa o caso de uso
Associar Projeto a WBS de Projeto de Parceira;
•
WBSDefinitionControl – Classe que implementa o caso de uso Definir
WBS;
•
LinkWBSToProjectControl – Classe que implementa o caso de uso
Associar Elemento de WBS a Projeto de Parceira;
•
PerformanceReportControl – Classe que implementa o caso de uso
Planejar e Relatar Desempenho de Projeto; e
•
EarnedValueAnalisysControl – classe que implementa o caso de uso
Análise de Valor Agregado.
131
MaintainPartnershipControl
<<instancia>>
ProjectDefinitionControl
LinkProjectToWBSControl
<<instancia>>
WBSDefinitionControl
PerformanceReportControl
LinkWBSToProjectControl
EarnedValueAnalisysControl
Figura 56: JavaPMSWeb - Classes da Camada de Controle de Fluxo de Casos de Uso.
5.3.4
A Camada de Serviços (services)
O pacote services representa a camada de serviços de software que interagem
com os objetos da camada de controle de fluxos de casos de uso expondo funcionalidades
como serviços Web. Ele é dividido em dois pacotes denominados provider e consumer
abrigando, respectivamente, as classes que implementam as funcionalidades expostas como
WS4PM e as classes que implementam seus consumidores. Um software que possui
funcionalidades expostas como serviços Web não precisa implementar consumidores para
eles. Isso foi uma decisão tomada exclusivamente em relação o JavaPMSWeb.
No pacote provider reside uma classe denominada PerformanceReport que
implementa uma funcionalidade que foi exposta como um serviço Web denominado
132
PerformanceReportService. Esse serviço permite o relato do desempenho entre projetos
relacionados.
Já
no
pacote
consumer
reside,
uma
classe
denominada
PerformanceReportProxy, que foi implementada a partir do documento WSDL, do serviço
Web comentado anteriormente, permitindo que o software atue também como consumidor
desse
serviço.
Uma
classe
denominada
PerformanceReportServiceInvoker
foi
desenvolvida para instanciar, devidamente, essa classe consumidora.
A Figura 57 exibe um Diagrama de Classes que ilustra o relacionamento entre a
classe
que
implementa
o
WS4PM
de
relato
de
desempenho
e
a
classe
PerformanceReportControl da camada controle de fluxos de caso de uso. Três métodos
podem
ser
invocados
remotamente:
inserPerformance,
updatePerformance
e
deletePerformance, possibilitando, respectivamente, o registro, a alteração e a exclusão de
relatos de desempenho de projetos relacionados. Estes métodos inicialmente invocam o
método isValidated que realiza uma validação dos parâmetros recebidos. Caso os parâmetros
estejam consistentes a transação é processada. Caso seja verificada alguma inconsistência nos
parâmetros recebidos, o método writeErrorLog registra num arquivo, informações referentes
à falha de processamento. Ao finalizar a operação, o WS4PM implementado retorna uma
mensagem indicando o sucesso ou a eventual falha. A partir de elementos dessa mensagem, o
consumidor pode verificar se a transação foi devidamente processada ou não.
PerformanceReport
-prc
insertPerformance()
updatePerformance()
deletePerformance()
isValidated()
writeErrorLog()
(from control)
Figura 57: JavaPMSWeb - Diagrama de Classes Envolvendo a Classe Exposta como WS4PM.
A Figura 58 exibe um Diagrama de Classes que ilustra o relacionamento entre as
classes PerformanceReportServiceInvoker e PerformanceReportProxy com a classe
PerformanceReportControl da camada de controle de fluxos de casos de uso. Neste caso, a
classe PerformanceReportControl instancia a classe da camada de entidades de negócio
133
denominada Performance ao executar uma operação de inclusão, alteração ou exclusão de
relato de desempenho para um determinado elemento da WBS de um projeto. Nesse momento
ela verifica se existe um projeto relacionado com este, e se for o caso, instancia um objeto da
classe
que
instancia
devidamente
a
classe
PerformanceReportProxy e executa o método correspondente à operação realizada
(inserção, alteração ou exclusão de relato de desempenho).
Ao invocar o WS4PM PerformanceReportService, provido pela eventual
empresa parceira de projeto, é obtida uma mensagem de retorno indicando o sucesso ou falha
da operação.
PerformanceReportProxy
PerformanceReportProxy()
insertPerformance()
updatePerformance()
deletePerformance()
createCall()
getEndPoint()
setEndPoint()
setURL()
getURL()
-srvc
-prsi
PerformanceReportServiceInvoker()
invokeService()
(from control)
Figura 58: JavaPMSWeb - Diagrama de Classes Envolvendo Classes Consumidoras do WS4PM
Implementado.
Maiores detalhes sobre a classe PerformanceReportProxy são fornecidos na Seção 5.4.
134
5.3.5
A Camada de Apresentação (presentation)
A camada denominada presentation refere-se à camada de apresentação do
JavaPMSWeb. Ela contém as interfaces de usuário comentadas na seção 5.2 que são
instaladas num Servidor de Aplicações Web a partir de uma pasta que é configurada como
“raiz de contexto da aplicação”.
O contêiner do Servidor de Aplicações Web hospeda os diversos arquivos de
código que implementam as interfaces de usuário e os demais componentes do software
desenvolvido. A Figura 59 exibe a estrutura de diretórios da pasta Web Content que
representa o contêiner Web para o JavaPMSWeb, ou seja, o local no servidor a partir do
qual se pode acessar seus recursos.
Figura 59: JavaPMSWeb - Estrutura de Diretórios Referente à Camada de Apresentação e o Contêiner
do Servidor de Aplicações
Para acessar uma determinada interface do software, a partir do Navegador Web, é
necessário informar seu endereço de localização no servidor, que também é conhecido como
URL. Este endereço é devidamente traduzido pelo servidor Web que acessa o recurso
135
solicitado e o disponibiliza ao usuário. Segue abaixo, uma breve descrição dos subdiretórios
apresentados na Figura 59:
•
admin – Hospeda as interfaces de gerenciamento dos serviços Web no
servidor de aplicações. Trata-se de uma aplicação Web denominada XML
SOAP Admin que está disponível em alguns servidores web que suportam
serviços Web em Java;
•
basics – Hospeda as interfaces desenvolvidas em JSP (Java Server Pages)
que permitem acesso às funcionalidades de manutenção de cadastros básicos
do JavaPMSWeb como o cadastro
de dados da empresa usuária e o
cadastro de dados de empresas parceiras de projetos;
•
images – Hospeda arquivos de imagens utlizadas na implementação das
interfaces de usuário;
•
javascripts – Hospeda arquivos contendo códigos em JavaScript que
implementam algumas funcionalidades nas interfaces, como por exemplo,
validação e controle de edição de campos em formulários, implementação de
menus de navegação e implementação da árvore de navegação que possibilita
o acesso a elementos da WBS de um projeto;
•
menu – Hospeda interfaces que implementam o menu principal do software;
•
META-INF – Diretório padrão do Servidor Aplicações Web que hospeda
arquivos de configuração do software em relação a ele;
•
projects – Hospeda as interfaces desenvolvidas em JSP que permitem aos
usuários realizarem a definição, planejamento e controle de projetos;
•
services – Hospeda os arquivos referentes às descrições dos WS4PM
(documentos em WSDL) implementados no software;
•
theme – Hospeda arquivos de configuração de estilos de visualização em
HTML que são utilizados na codificação das interfaces;
•
WEB-INF – Diretório padrão do Servidor de Aplicações Web que hospeda
as classes compiladas das demais camadas do software e as bibliotecas
(componentes de software de terceiros) exigidas pelo mesmo.
A Figura 60 exibe um diagrama da UML, denominado Diagrama de Instalação,
que fornece uma visão dos componentes de instalação que suportam a execução do protótipo
JavaPMSWeb, bem como as aplicações clientes, que interagem com ele. As funções de
136
suporte ao software podem ser desempenhadas por um único servidor ou distribuídas entre
vários, de forma que se tenha servidores com funcionalidades específicas.
Sistema de
Gerenciamento de Banco
de Dados Relacional
Navegador Web.
Suporte às tecnologias:
- HTML;
- JavaScript; e
- Java Server Pages.
Servidor de Aplicações Web
Cliente Web
<<Rede TCP/IP>>
Contêiner
Web
JPMSClient
Aplicativo
Windows
desenvolvido
em .NET
SGBDR
<<Rede TCP/IP>>
Contêiner Web com suporte a:
- Páginas Web;
- Aplicativos Java;
- Servlets e Java Server Pages;
- Mensagens SOAP/XML; e
- Documentos WSDL.
Figura 60: JavaPMSWeb - Diagrama de Instalação.
5.4 Detalhes da Implementação do Serviço Web
O desenvolvimento de serviços Web exige um considerável esforço de
programação tanto em sua implementação quanto em sua descrição e instalação num Servidor
de Aplicações Web. Esse desenvolvimento atualmente é viabilizado por ferramentas de
auxílio à programação de software, conhecidas como ferramentas RAD (Rapid Application
Developer), que já possuem mecanismos de auxílio à produção e disponibilização de serviços
Web.
137
Esta seção apresenta alguns detalhes da implementação tanto do WS4PM que
permite o relato de desempenho entre projetos relacionados, quanto de aplicações
consumidoras.
5.4.1
O Serviço Web de Relato de Desempenho
Para implementar o WS4PM de relato de desempenho no JavaPMSWeb,
desenvolveu-se a classe denominada PerformanceReport que se preocupa apenas em expor
a funcionalidade de relato de desempenho utilizando a classe PerformanceReportControl,
que lida com classes da camada de entidades de negócio invocando devidamente seus
métodos.
De posse dessa classe utilizou-se uma funcionalidade provida pela ferramenta
RAD utilizada, que, a partir de algumas informações que vão sendo solicitadas num
procedimento “passo a passo”, produz todo o código necessário para expô-la como um
serviço Web.
Num próximo passo foi necessário registrar a classe, que implementa o serviço
num servidor de aplicações Web que oferece suporte a mensagens SOAP. Além disso, foram
implementados alguns arquivos, conforme a especificação WSDL, que descrevem o serviço e
permitem a implementação de softwares consumidores. O conteúdo desses arquivos pode
estar contido em um ou em vários arquivos WSDL, criados conforme as principais seções de
um documento desse tipo. No caso da descrição estar distribuída em vários arquivos, estes
possuem cláusulas de importação de conteúdo de uns nos outros. Esses arquivos são
documentos em XML que também são publicados no servidor de aplicações Web, podendo
ser acessados por meio da Internet e visualizados em Navegadores Web.
No caso do WS4PM implementado, a descrição foi concebida em 3 (três) arquivos
WSDL, conforme sugerido pela ferramenta RAD utilizada. A finalidade de cada um dos três
arquivos é a seguinte:
•
PerformanceReporService.wsdl – Documento que descreve o serviço
Web
como
um
todo.
Este
PerformanceReportBinding.wsdl;
arquivo
importa
o
arquivo
138
•
PerformanceReportBinding.wsdl – Documento que descreve as ligações
do serviço Web. Este arquivo importa o arquivo PerformanceReport.wsdl;
e
•
PerformanceReport.wsdl – Documento que descreve as interfaces do
serviço Web.
Detalhes sobre documentos WSDL podem ser obtidos na Seção 3.3.3.
O WS4PM implementado é um serviço Web orientado a RPC cujo modelo de
processamento é centrado em objetos. Esta estrutura faz com que a interação entre provedores
e consumidores seja realizada de forma síncrona. A escolha desse modelo de implementação
não que dizer que este seja o mais apropriado para o serviço Web em questão.
O WS4PM de relato de desempenho foi registrado num servidor UDDI, no caso, o
da IBM que está disponível no endereço http://uddi.ibm.com. Ferramentas RAD, como o
WSAD por exemplo, possuem interfaces que propiciam o acesso a esses servidores,
facilitando o teste e a manutenção de registros UDDI tanto de informações sobre a empresa
quanto dos serviços Web que ela dispõe.
Ao registrar um serviço Web num servidor UDDI é solicitada a URL do arquivo
WSDL que o descreve. Quando uma URL válida é informada, o servidor UDDI acessa o
referido arquivo WSDL e obtém as informações necessárias como, por exemplo, a localização
do provedor.
A Figura 61 exibe a interface do serviço UDDI, provido pela IBM, onde foi
publicado o serviço Web implementado. Nota-se que os campos Businesses, Services e
Technical Model registram, respectivamente, informações sobre um negócio, um serviço
Web e um tModel do serviço Web em questão, podendo ser adicionados outros. Maiores
detalhes sobre os elementos de registros UDDI podem ser obtidos na Seção 3.3.4.
139
Figura 61: Registro UDDI do WS4PM Implementado.
5.4.2
Consumidores do Serviço Web de Relato de
Desempenho
Assim como na implementação de um serviço Web, algumas ferramentas RAD,
oferecem ferramentas que facilitam também a criação de programas consumidores desses
serviços, bastando para isso, fornecer o arquivo WSDL que o descreve.
No caso do WS4PM de relato de desempenho, que como já foi dito, é orientado a
RPC, o desenvolvimento de um consumidor
requer a implementação de uma classe
conhecida como Proxy. Ela contém a codificação necessária para estabelecer a conexão com o
provedor do serviço Web e efetuar a chamada de procedimento remoto utilizando o protocolo
HTTP para transportar envelopes SOAP.
Foram desenvolvidos dois consumidores: um baseado na tecnologia Java e outro
baseado na tecnologia Microsoft .NET.
140
O consumidor baseado na tecnologia Java é uma classe denominada
PerformanceReportProxy que reside no pacote consumer da camada services. Ela possui
a seguinte estrutura básica:
•
Um método construtor da classe, que invoca um método que cria uma
conexão HTTP, para comunicação, via SOAP, com o provedor do serviço
Web;
•
Um método correspondente a cada método exposto no serviço Web. Cada
um desses métodos define os valores dos parâmetros e invoca os
procedimentos remotos por meio de um objeto denominado call;
•
Um método que cria uma conexão HTTP com o provedor do serviço para
propiciar a comunicação via protocolo SOAP; e
•
Um conjunto de métodos que permite definir uma propriedade, em tempo de
execução, referente ao endereço URL do ponto de acesso do serviço Web.
A Figura 62, que é uma das formas de representação de classes na UML, ilustra a
estrutura da PerformanceReportProxy.
Figura 62: A Classe Consumidora (Proxy) do WS4PM Implementado.
141
O consumidor do WS4PM implementado com base na tecnologia .NET foi
desenvolvido utilizando-se a linguagem C# e recebeu o nome JPMSClient. Este software
interopera com o JavaPMSWeb inserindo, alterando e excluindo relatos de desempenho.
Para sua implementação, foi utilizado o Microsoft Visual Studio .NET, que é uma ferramenta
RAD para desenvolvimento de software na plataforma .NET da Microsoft. Esta ferramenta
também disponibiliza funcionalidades de auxílio ao desenvolvimento, tanto da porção
provedora quanto da porção consumidora de serviços de software.
A implementação de serviços Web na plataforma .NET também requer que o
software, que implementa a funcionalidade, seja hospedado num contêiner de um servidor de
aplicações Web, que nesse caso é representado pelo IIS (Internet Information Service). Outro
detalhe é que os métodos de classes de software que serão publicados como serviços Web
devem possuir antes de sua assinatura (definição) o comando-chave [WebMethod]. A
presença desse comando indica ao compilador e ao instalador, presentes no Visual Studio, que
o método em questão é uma operação que pode ser invocada remotamente via SOAP.
5.5 Cenário de Testes
No JavaPMSWeb, determinados elementos da WBS de projetos, da empresa
usuária do software, podem ser associados a empresas parceiras de projeto delegando seu
desenvolvimento a elas. O inverso também é possível, ou seja, um dado projeto da empresa
usuária do software pode ser relacionado com o elemento da WBS de um determinado projeto
de uma empresa parceira, que nesse caso figura como líder (Project Owner) de um projeto de
larga escala envolvendo empresas parceiras.
A Figura 63 ilustra o cenário de testes utilizado. Foram instaladas duas cópias do
JavaPMSWeb em servidores diferentes, simulando a situação em que duas empresas
parceiras utilizam o mesmo software de gestão de projetos. Uma cópia do JPMSClient foi
instalada em outra estação simulando uma terceira empresa, que também é parceira das duas
primeiras, mas utiliza um software desenvolvido com uma tecnologia distinta. Independente
das tecnologias que suportam esses produtos, eles interoperam utilizando a tecnologia de
serviços Web por meio de uma intranet ou da Internet permitindo o relato de desempenho
entre projetos relacionados.
142
Consome WS4PM
Provê WS4PM
Figura 63: Cenário de Testes dos Protótipos de Software Desenvolvidos.
Para descrever melhor o cenário apresentado na figura acima, considere que a
empresa situada no Brasil pretende lançar um novo produto no mercado. Porém, este produto
é de alta tecnologia e de grande magnitude, o que permite qualificar o projeto para sua
concepção e lançamento como sendo um projeto de larga escala. A empresa brasileira não
detém toda a tecnologia e recursos suficientes para concebê-lo sozinha e então ela propõe uma
parceria a duas outras empresas, uma americana e a outra alemã.
143
Por coincidência, a empresa americana utiliza o mesmo software de gestão de
projetos que a empresa brasileira, nesse caso o JavaPMSWeb. Mas o mesmo não ocorre em
relação à empresa alemã que possui outro fornecedor desse mesmo tipo de ferramenta e,
portanto, utiliza um produto distinto, o JPMSClient.
Partindo do pressuposto que estes softwares estão dotados de um WS4PM que
permita o relato de desempenho entre projetos relacionados, a empresa brasileira define o
projeto do produto, como um todo, no JavaPMSWeb e delega um elemento da WBS à
empresa americana e outro à empresa alemã. Dessa forma, todas as informações de relato de
desempenho para esses componentes ficam a cargo das referidas empresas parceiras.
A empresa americana e a empresa alemã definem internamente, um projeto para
conceber o componente que lhes foi delegado e relacionam seus projetos ao projeto de larga
escala que foi definido no software da empresa brasileira.
Conforme algumas regras implementadas no JavaPMSWeb, a empresa brasileira
consegue efetuar o lançamento de valores referentes ao planejamento e controle apenas dos
elementos da WBS que não foram delegados a nenhuma empresa parceira. Essas por sua vez,
efetuam o lançamento de valores referentes ao planejamento e controle de seus projetos, sem
se preocupar em reportar esses valores à empresa líder do projeto de larga escala relacionado,
pois os softwares de gestão de projetos interoperam permitindo o planejamento e controle
destes, de forma integrada.
A verificação da troca de mensagens SOAP entre o consumidor e o provedor de
um serviço Web, pode ser realizada com o auxílio de uma ferramenta intitulada TCP Monitor
que é configurada (colocada) entre eles, mais especificamente, no lado do provedor. Todas as
requisições feitas pelo consumidor são endereçadas à porta de comunicação configurada na
ferramenta que por sua vez retransmite a requisição para o servidor de aplicações que hospeda
o serviço Web. A resposta do servidor de aplicações é encaminhada para a referida ferramenta
que a retransmite para o consumidor. Tudo isso é feito sem interferir no conteúdo das
mensagens trocadas. A Figura 64 apresenta a interface do TCPMonitor que pode ser obtido
junto com um kit de ferramentas para desenvolvimento disponibilizado, gratuitamente, pela
IBM, o WSDK (Web Services Development Kit).
O conteúdo em XML, da Figura 65, representa a mensagem SOAP de invocação
do WS4PM implementado, e é justamente, o conteúdo apresentado na caixa de texto superior
da interface apresentada na Figura 64.
Nota-se, no código da Figura 65, que o serviço Web é devidamente identificado e
uma série de parâmetros são recebidos (partnerId, projectId, etc). Ao processar a requisição
144
do consumidor do WS4PM, o servidor de aplicações do provedor retorna a mensagem SOAP,
como a ilustrada na Figura 66, contendo o resultado da transação.
A mensagem de resposta à invocação do serviço Web é apresentada na caixa de
texto inferior da interface ilustrada na Figura 64.
Como o JavaPMSWeb foi concebido de forma que ele pode interoperar com
outras cópias instaladas em servidores conectados a uma rede, pode ser desenvolvido um
estudo de caso envolvendo vários níveis de parceria de projeto.
Figura 64: Interface da Ferramenta "TCP Monitor".
145
A Figura 67 e a Figura 68 apresentam dois Diagramas de Seqüência. Esse tipo de
diagrama, proposto pela UML, é elaborado nas primeiras iterações e refinado ao longo do
processo de desenvolvimento do sofware no intuito de se especificar como o sistema em
desenvolvimento irá implementar uma dada funcionalidade (caso de uso). Os elementos
PerformanceReportProxy e Service:PerformanceReport representam, respectivamente,
um componente “Consumidor de Funcionalidade” e um componente “Provedor de
Funcionalidade”, citados na Seção 4.2.
POST /JavaPMSWeb/servlet/rpcrouter HTTP/1.0
Host: fcmf23646.fcmf.ita.br
Content-Type: text/xml; charset=utf-8
Content-Length: 913
SOAPAction: ""
<?xml version='1.0' encoding='UTF-8'?>
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<SOAP-ENV:Body>
<ns1:updatePerformance
xmlns:ns1="http://tempuri.org/edu.oam.javapms.services.provider.PerformanceReport" SOAPENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<partnerId xsi:type="xsd:string">GE</partnerId>
<projectId xsi:type="xsd:string">ERJ-135</projectId>
<wbsItemId xsi:type="xsd:string">3</wbsItemId>
<partnerProjectId xsi:type="xsd:string">AV-ERJ</partnerProjectId>
<statusDate xsi:type="xsd:int">2</statusDate>
<plannedValue xsi:type="xsd:double">1000.0</plannedValue>
<earnedValue xsi:type="xsd:double">1000.0</earnedValue>
<actualCost xsi:type="xsd:double">1000.0</actualCost>
</ns1:updatePerformance>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
Figura 65 : Mensagem SOAP de Invocação do WS4PM Implementado.
146
HTTP/1.1 200 OK
Server: WebSphere Application Server/5.0
Set-Cookie: JSESSIONID=0000ILJYOWCICHRYYQOH1OWSWCY:-1;Path=/
Cache-Control: no-cache="set-cookie,set-cookie2"
Expires: Thu, 01 Dec 1994 16:00:00 GMT
Content-Type: text/xml; charset=utf-8
Content-Length: 603
Content-Language: pt-BR
Connection: close
<?xml version='1.0' encoding='UTF-8'?>
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<SOAP-ENV:Body>
<ns1:updatePerformanceResponse
xmlns:ns1="http://tempuri.org/edu.oam.javapms.services.provider.PerformanceReport" SOAPENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<return xsi:type="xsd:string">Op:Update - Project Id: Ok - WBS Item Id: Ok Final Result:
Success!</return>
</ns1:updatePerformanceResponse>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
Figura 66: Mensagem SOAP de Resposta à Invocação do WS4PM Implementado.
A operação representada nos referidos diagramas é a de alteração de relato de
desempenho (updatePerformance), que é parte do caso de uso Planejar e Relatar
Desempenho de Projeto. Por meio desses diagramas é possível visualizar, em certo nível
de abstração, a troca de mensagens entre objetos do JavaPMSWeb quando da invocação do
serviço de relato de desempenho, por parte de uma empresa parceira de projeto, e também,
quando do processamento dessa invocação por parte da empresa líder do projeto. Nota-se que,
caso o projeto da empresa líder esteja relacionado com o de um terceiro, é possível uma nova
invocação ao WS4PM eventualmente provido pela terceira empresa.
147
: Equipe de Gestão : PerformanceReportForm
:
de Custos
PerformanceReportCo...
: WBSItem
: Project : Performance : LinkToProject : Partner
: DataAccess : PerformanceReportServiceInvoker : PerformanceReportProxy
: Software de Gestão
de Projeto de Parceira
//updatePerformance
//updatePerformance
//getDBInfo
//readData
//getProject
//getDBInfo
//readData
//getLinkToProject
//getDBInfo
//readData
//getPartner
//getDBInfo
//readData
//dbInsert
//writeData
//invokeService("update")
//setURL
//setURI
//createCall
//updatePerformance
//showAllPerformance
Figura 67: JavaPMSWeb - Diagrama de Seqüência da Invocação de WS4PM de Relato de Desempenho.
148
: Sof tware de
Gestão de Proj...
: DataAccess
Serv ice : Perf ormanceReport
:
Perf ormanceReportCo...
//updatePerf ormance
: Perf ormanceReportServ iceInv oker : Perf ormanceReportProxy
: WBSItem : Project : Perf ormance : LinkToProject : Partner
: Software de Gestão de
Projeto de Parceira
//isValidated
//getDBInf o
//readData
//getProject
//getDBInf o
//readData
//getLinkToProject
//getDBInf o
//readData
//getPartner
//getDBInf o
//readData
//dbInsert
//writeData
//inv okeServ ice("update")
//setURL
//setURI
//createCall
Figura 68: JavaPMSWeb - Diagrama de Seqüência de Processamento da Invocação do WS4PM de Relato de Desempenho.
149
Este capítulo apresentou alguns detalhes da implementação dos dois protótipos de
software de gestão de projetos, que foram concebidos em tecnologias distintas para testar e
validar tanto a solução, baseada na interoperabilidade de software, quanto a tecnologia de
serviços Web, que a propicia.
A utilização de um serviço UDDI, disponível na Internet, também é descrita no
intuito de mostrar a viabilidade desse componente da arquitetura de serviços Web, que
permite aos novos parceiros de projetos obterem, por meio da Web, informações sobre os
negócios uns dos outros e sobre os WS4PM que estes possuem implementados em seus
softwares de gestão de projetos.
Um caso de testes foi desenvolvido, apresentando o cenário no qual empresas
parceiras podem gerenciar projetos relacionados de forma integrada, mesmo utilizando
softwares distintos e estando separadas geograficamente.
O desenvolvimento dos protótipos, principalmente do JavaPMSWeb, em
camadas propiciou facilidades na implementação do WS4PM de relato de desempenho, uma
vez que a classe que implementa o serviço (PerformanceReport) simplesmente instancia a
classe PerformanceReportControl, da camada de controle de fluxos de casos de uso, valida
os parâmetros recebidos e invoca métodos que tratam e processam as informações como se a
invocação estivesse sido realizada localmente.
Alguns detalhes da implementação do protótipo JavaPMSWeb, como por
exemplo, a modelagem de determinados atributos e classes que permitem o relacionamento de
projetos, controle de transações, segurança, e outros requisitos não funcionais de sistemas
distribuídos, mostram que a implementação dos WS4PM em softwares já existentes requer
algumas adaptações nos mesmos, de forma a conformar com esses requisitos.
Por meio da implementação do estudo de caso referente à Análise de Valor
Agregado pôde-se constatar a viabilidade tanto da solução, quanto da tecnologia proposta. As
funcionalidades de relato de desempenho implementadas nos protótipos sempre verificam se o
projeto em questão está relacionado com outro e, caso afirmativo, invocam o respectivo
WS4PM provido pelos eventuais parceiros, replicando a operação nos sistemas destes. A
implementação realizada permite o planejamento e controle de projetos envolvendo vários
níveis de parcerias.
150
O desenvolvimento de serviços Web, se for realizado manualmente, é algo
consideravelmente trabalhoso, principalmente no tocante à composição dos códigos de
descrição (WSDL), scripts de instalação exigidos pelos Servidores de Aplicações Web e
interpretação de documentos WSDL para a implementação de consumidores. Porém, as
ferramentas RAD como o WSAD, Jbuilder e o Visual Studio .NET, estão dotadas de
mecanismos que auxiliam o desenvolvedor nessas tarefas, permitindo a este, abstrair uma
série de detalhes.
O conjunto de informações apresentadas nesse capítulo, bem como sua estrutura,
permite afirmar que este é uma espécie de Documento de Arquitetura do protótipo
JavaPMSWeb, outro artefato sugerido pelo RUP (RATIONAL, 2002b), pois são
apresentadas pelo menos três visões relacionadas ao referido software: uma visão de casos de
uso, uma visão lógica (descrição das camadas) e uma visão de instalação.
Seguem, no próximo capítulo, as conclusões, contribuições e recomendações de
trabalhos futuros referentes aos WS4PM.
151
6 Capítulo VI
Conclusões, Contribuições e Sugestões de
Trabalhos Futuros
6.1 Conclusões
A produtividade e qualidade do trabalho referentes à gestão de projetos de larga
escala envolvendo empresas parceiras são afetadas por fatores como a dispersão geográfica
dos envolvidos e a grande diversidade de tecnologias de apoio à gestão de projetos adotadas
de forma independente por eles. Disso decorre um grande volume de retrabalho,
principalmente no tocante ao registro de informações que fazem parte de relatórios da gestão
de projetos e que tramitam entre as empresas parceiras e a empresa lider.
Pode-se então concluir que os WS4PM representam uma forma de prover a
interoperabilidade entre softwares de gestão de projetos, tendo como base a tecnologia de
serviços Web, que, como pode ser observado, principalmente nos detalhes de implementação
dos protótipos apresentados no Capítulo V, é uma alternativa válida para isso.
Para o sucesso de um projeto com parceiros, um dos fatores chaves é dispor de
processos de negócios dos envolvidos integrados e otimizados para o projeto. Durante o
levantamento de requisitos, percebeu-se que vários processos nem sempre oferecem boa
integração e otimização, dificultando o trabalho de gestão de projetos e levantamento de
requisitos. Dessa forma, acredita-se que é importante uma investigação sobre a modelagem de
processos, nesse tipo de projeto, visando a realização da integração de forma eficiente.
Para finalizar, acredita-se que a alternativa de solução WS4PM, considerando os
processos de negócio devidamente integrados, venha a contribuir muito para a gestão de
projetos de larga escala envolvendo empresas parceiras, aumentando a sinergia entre elas.
152
6.2 Contribuições
No tocante a contribuições específicas, pode-se citar o seguinte:
a) A especificação de requisitos de interoperabilidade pertinentes à gestão de
projetos de larga escala envolvendo empresas parceiras; e
b) A especificação de um modelo computacional que pode vir a ser
aproveitado por desenvolvedores de softwares de gestão de projetos no
intuito de prover a interoperabilidade de seu produto com outros existentes
no mercado.
Podem ser consideradas contribuições secundárias, o seguinte:
a) A investigação dos conceitos de gestão de projetos focando projetos de
larga escala envolvendo empresas parceiras; e
b) Um conjunto de artefatos que podem ser utilizados como ponto de partida
para o desenvolvimento de trabalhos futuros.
Um resumo deste trabalho e de suas principais contribuições, encontra-se no artigo
intitulado “A Interoperabilidade de Software no Auxílio à Gestão de Projetos de Larga Escala
que Envolvem Parceiros”, que foi apresentado no IV Congresso Ibero-Americano de
Gerenciamento de Projetos, promovido pelos capítulos ibero-americanos do PMI nas cidades
de São Paulo e Rio de Janeiro de 17 a 21 de Novembro de 2003.
6.3 Sugestões de Trabalhos Futuros
Este trabalho apresenta um modelo de solução para a interoperabilidade de
softwares de gestão de projetos que implementam funcionalidades relacionadas com a
metodologia de gestão de projetos proposta pelo PMBOK (PMI, 2000). Podem ser
desenvolvidos trabalhos nesta mesma linha que tenham como base outras metodologias.
Os requisitos dos WS4PM foram especificados num nível de abstração
consideravelmente alto, e como apenas um caso de uso foi tratado neste trabalho, o referente a
relato de desempenho entre projetos relacionados, não foi executada a modelagem de casos de
uso, uma das atividades previstas pelo RUP, para se entender as interações dos atores
(usuários e outros sistemas) com o sistema proposto e estruturar a solução como um todo.
Sendo assim, sugere-se a execução desta atividade em trabalhos futuros.
153
Trabalhos específicos podem ser desenvolvidos com o objetivo de especificar o
modelo de interação (RPC ou Mensagens), o tipo de processamento (Centrado em Objetos ou
Centrado em Documentos) e o tipo de interação (síncrona ou assíncrona) mais adequado a
cada um dos WS4PM especificados.
Podem ser desenvolvidos trabalhos específicos focando os requisitos não
funcionais especificados para os WS4PM. Esses trabalhos podem tratar de forma isolada,
componentes da GXA, especificando, por exemplo, modelos de segurança, transação,
roteamento, coordenação e anexos.
Como consta no escopo deste trabalho, não foi tratada aqui, a interoperabilidade
entre softwares de gestão de projetos com outras ferramentas computacionais utilizadas no
auxílio à gestão de projetos. Fica como sugestão para trabalhos futuros a especificação de uma
solução que propicie também a integração dos softwares de gestão de projetos com os demais
softwares utilizados nos processos, como por exemplo, os ERPs.
154
7 Referências Bibliográficas
AHMED, K. Z.; UMRYSH, C. E. Developing enterprise Java applications with J2EE.
Boston: Addison-Wesley, 2001. 368 p.
AHMED, Kall et al. Professional JAVA XML. Birmingham: Wrox Press, 2001. 1159 p.
BOND, Martin et al. Sams teach yourself J2EE in 21 days. Indianapolis: SAMS, 2002. 1100
p.
BRITTENHAN, Peter. Web services development concepts: WSDC 1.0. IBM, 2001.
Disponível em <http://www-4.ibm.com/software/solutions/webservices/pdf/WSDC.pdf >
Acesso em: 05 mai. 2001.
COSTA, Geraldo. O modelo de Web services: como desenvolver aplicações em uma nova
arquitetura de software. São Paulo: Publicação Técnica Promon Tecnologia. 2002. 12p.
(Business et Technology Review Series, ano 2, n. 4)
CURBERA, Francisco et. al. Using WSDL in a UDDI registry, version 1.07 – UDDI best
practice. 2001. Disponível em <http://www.uddi.org/pubs/wsdlbestpractices-V1.07-Open20020521.pdf> Acesso em: 05 mai. 2001.
DEMICHILLIE, Greg. Global XML web services architecture (GXA). 2002. Disponível
em:<http://www.directionsonmicrosoft.com/sample/DOMIS/update/2002/10oct/1002gdffws.h
tm>Acesso em 31 out. 2002.
EMBRAER. Equipe de Gestão do Programa EMBRAER 170/190. Slides de apresentação do
modelo de gestão do programa EMBRAER 170/190. São José dos Campos: Embraer,
2002.
EMBRAER. Perfil da empresa. Disponível em <www.embraer.com.br >. Acesso em 10
Ago. 2002.
FLEMMING, Q. W.; KOPPELMAN, Joel M. Earned value project management. 2. Ed.
[S.l.]: Project Management Institute, 2000.
155
GRADY, Robert. Practical software metrics for project management and process
improvement. [S.l.]: Prentice-Hall, 1992. 270p.
HALL, Marty; BROWN, Larry. Core WEB programming: the sun microsystem press
JAVA series. 2.Ed. [S.l.]: Sun Microsystem, 2001. 1398 p.
HENDRICKS, Marck et al. Professional Java web services. [S.l.]:Wrox Press, 2002.
IBM. Web service security (ws-security). Ver. 1.0. 2002. Disponível em <http://www106.ibm.com/developerworks/library/ws-jsr109-proposed> Acesso em: 01 abr. 2002.
IONA Technologies. Desenvolvendo uma estratégia em web services. In: SEMINÁRIO
LIVEWARE: A REALIDADE DOS WEB SERVICES, 2002, São Paulo. Anais... São Paulo,
2002.
IONA Technologies. Web services: realidade IONA. In: SEMINÁRIO LIVEWARE: A
REALIDADE DOS WEB SERVICES, 2002, São Paulo. Anais... São Paulo, 2002.
KERZNER, Harold. Project management: a system approach to planning scheduling and
controlling. New York: VNR, 1997. 912 p.
KRUCHTEN, Philippe. The rational unified process – An introduction – 2nd ed.
USA:Addison-Wesley, 2000. 298p.
LAUDON, K.C. Management information systems: organization and technology in the
networked enterprise. [S.l.]: Prentice Hall, 2000. 588p.
MCCARTY, Bill; CASSADY-DORION, Luke. JAVA distributed objects: the authoritative
solution. [S.l.]: SAMS Publishing, 1998.
MICROSOFT Corp. Microsoft biztalk server homepage. Disponível em
<http://www.microsoft.com/biztalk> Acesso em: 20 jan. 2003.
Microsoft Corp. Microsoft host integration server homepage. Disponível em
<http://www.microsoft.com/brasil/hiserver/default.stm> Acesso em: 25 jan. 2003.
MYRON, Hura et al. Interoperability: A Continuing Challenge in Coalition Air Operations.
[s.l.]: RAND Research Publications, 2000, 235p. Cap. 2. Versão digital disponível em
<http://www.rand.org/publications/MR/MR1235> Acesso em: 25 mar. 2002.
NEWCOMER, Eric. Decide between J2EE and .NET web services. Disponível em
<http://www.fawcette.com/dotnetmag/2002_10/magazine/columns/webservices/defaultpf.asp
> Acesso em: 01 out. 2002.
156
NICHOLAS, John M.. Managing business and engineering projects: concepts and
implementation. [S.l.]: Prentice Hall. 496p. 1990;
PMI – Project Management Institute. PMBOK 2000 - a guide to the project management
body of knowledge. [S.l.]: PMI, 2000.
PMI – Project Management Institute. Project Management Institute practice standard for
work breakdown structures. Newtown Square, Pennsylvania, USA, 2001. 82p.
QUATRANI, Terry. Visual modeling with Rational Rose 2000 and UML.USA:AddisonWesley, 2000. 256p.
RATIONAL Software Corp. Rational suite introduction – version 2002.05.00:
documentação do produto. [S.l.], 2002.
RATIONAL Software Corp. Rational unified process – version 2002.05.00: processo de
desenvolvimento de software. [S.l.], 2002.
SEMINÁRIO SOBRE GERÊNCIA DE REQUISITOS. 2001, Campinas. Anais... Campinas:
LIVEWARE Tecnologia a Serviço, 2001.
SHIRAZI, Jack. Web Service performance tips. Disponível em
<http://www.javaperformancetuning.com/tips/webservice.shtml> Acesso em: 15 mar. 2003.
SKONNARD, Aaron. Publishing and discovering web services with DISCO and UDDI.
Disponível em <http://www.msdn.microsoft.com> Acesso em: 25 out. 2002.
SNELL, James. Implementing web services – part 1. Disponível em <http://www106.ibm.com/developerworks> Acesso em: 14 mai. 2002.
SNELL, James. Implementing web services – part 2. Disponível em <http://www106.ibm.com/developerworks> Acesso em: 5 mai. 2002.
SUN Microsystems. The Java web services tutorial. [S.l.]: SUN Microsystems, 2002.
Disponível em <http://java.sun.com> Acesso em: 25 mar. 2002.
SUN Microsystems. Using web services effectively. Disponível em
<http://Java.sun.com/blueprints/webservices/using/webservbp.html> Acesso em: 01 out.
2002.
SUN Microsystems. The J2EE tutorial - a beginner's guide to developing enterprise
applications on the JavaTM 2 platform, enterprise edition SDK version 1.3. Disponível em
<http://Java.sun.com/j2ee/tutorial/1_3-fcs/index.html> Acesso em: 22 dez. 02.
157
SUN Microsystems. J2EE connector architecture. Disponível em
<http://Java.sun.com/j2ee/connector/> Acesso em: 22 dez. 02.
TELELOGIC North America Inc. Get it right the first time: writing better requirements:
telelogic DOORS/ERS manuals. [S.l.], 2001.
VALERIANO, Dalton L. Gerência em Projetos – Pesquisa, Desenvolvimento e
Engenharia. São Paulo:Makron Books, 1998. Cap. 7, p.191-213.
VAWTER, Chad; RONAM, Ed. J2EE vs. Microsoft .NET: a comparision of building
XML-based web services. Disponível em <www.theserverside.com/resources/pdf/J2EE-vsDotNET.pdf> Acesso em: 01 out. 2002.
WIEGERS, Karl E. Automating requirements management. Disponível em
<www.processimpact.com/articles/rm_tools.html> Acesso em: 17 ago. 2002.
WORLD Wide Web Consortium. Web service description language. Ver. 1.2. W3C, 2002.
Disponível em <http://www.w3.org/2002/ws/> Acesso em: 21 out. 2002.
WORLD Wide Web Consortium.XML schema part 2: datatypes - W3C recommendation:
W3C, 2001. Disponível em <http://www.w3.org/TR/xmlschema-2/> Acesso em: 21 out.
2002.
YANO, E. T. GroupPlaces: uma arquitetura de groupware para a WWW. 141f. 1998. Tese
(Doutorado em Informática) – Instituto Tecnológico de Aeronáutica, São José dos Campos.
158
8 Glossário
API - Application Programming Interface: interface de programação provida por sistemas de
software para viabilizar o desenvolvimento de aplicações. As aplicações desenvolvidas fazem
uso do sistema de software por meio de chamadas de procedimentos, comandos e respostas
específicas numa interface bem definida.
B2B – Business To Business: negociação entre empresas fornecedoras e consumidoras,
auxiliada por recursos da Internet, estreitando o relacionamento entre elas e agilizando
processos de negociação para oferecer produtos e serviços.
B2Bi – Business To Business Integration: modalidade de integração, por meio da Web, de
sistemas heterogêneos ou não, realizada entre organizações distintas no intuito de estreitar
relacionamentos de parceria comercial.
B2C – Business To Consumer: negociação entre empresa e consumidor final, auxiliada por
recursos da Internet, estreitando o relacionamento entre eles e agilizando processos de
negociação.
B2Ci – Business to Consumer Integration: modalidade de integração, por meio da Web, de
sistemas heterogêneos ou não, realizada entre organizações distintas no intuito de estreitar
relacionamentos do tipo cliente/fornecedor.
Back-end: Em sistemas de software, ao contrário de front-end, refere-se à porção tecnológica
que geralmente não é percebida pelo usuário final, mas que suporta a aplicação, por exemplo,
Sistemas de Gerenciamento de Bancos de Dados.
Binding: ligação, conexão entre dois pontos remotos.
Bottom-Up: Na abordagem para desenvolvimento de serviços Web, utilizada pelo Provedor,
refere-se ao desenvolvimento de um serviço Web a partir de uma aplicação existente.
Bytecode: código gerado pelo compilador Java e executado pelo interpretador Java,
independente do hardware ou sistema operacional.
159
CORBA - Common Object Request Broker Architecture: arquitetura para a distribuição de
objetos em ambientes distribuídos independente do sistema operacional em uso.
CLR – Common Language Runtime: máquina computacional abstrata responsável pela
independência da plataforma Microsoft .NET quanto à linguagem de programação utilizada
no desenvolvimento de software.
DCOM – Distributed Component Object Model: arquitetura semelhante a CORBA utilizada
na distribuição de objetos em Ambientes Distribuídos Microsoft, apenas.
Deliverable: produto tangível e verificável, resultante de um trabalho, como por exemplo, um
estudo de viabilidade, um projeto lógico detalhado ou um protótipo.
Download: ação de obter um determinado arquivo a partir de um servidor conectado à
Internet, gravando-o na estação de trabalho local.
EAI - Enterprise Application Integration: modalidade de integração de sistemas
computacionais heterogêneos, existentes dentro das fronteiras de uma organização.
EAP – Estrutura Analítica do Projeto: Vide WBS.
ebXML – electronic business eXtensible Markup Language: padrão de indústria semelhante ao
UDDI, porém com escopo diferente, desenvolvido para possibilitar o registro de informações
de empresas interessadas em realizar comércio eletrônico.
EJB – Enterprise Java Bean: elemento da plataforma de desenvolvimento de software J2EE
que pode ser estendido e reutilizado para implementar componentes de um aplicativo
suportado por um servidor de aplicações.
ERP – Enterprise Resource Planning: Sistema de Gestão de Empresarial integrado, que visa
integrar os processos funcionais de uma empresa.
Firewall: tecnologia utilizada para evitar que usuários não autorizados acessem recursos
disponíveis em servidores conectados à Internet.
Front-end: Em sistemas de software, ao contrário de back-end, refere-se à porção que
geralmente é percebida pelo usuário, pois é por meio dela que ele interage com ela, por
exemplo, as interfaces gráficas ou textuais.
160
Green Field: abordagem para desenvolvimento de serviços Web, utilizada pelo Provedor, cuja
aplicação e o serviço Web inicialmente, não existem. A aplicação é implementada e na
seqüência é disponibilizada como um serviço Web gerando e publicando sua interface.
Groupware: Sistemas computacionais que visam suportar e assistir o trabalho em grupo.
GXA – Global XML Architecture: Arquitetura Global de XML. É um conjunto de
especificações construídas sobre XML, que são blocos de construção para a implementação
de serviços Web dotados das habilidades como segurança, controle de transações, mensagem
confiável, dentre outras.
HTTP – Hipertext Transfer Protocol: protocolo de transporte utilizado para acesso a certos
recursos na Internet, geralmente, públicos.
HTTPS - Hipertext Transfer Protocol Secure: extensão do HTTP que provê segurança das
informações quando de seu transporte, permitindo comunicação segura entre dois pontos da
Web.
IDL – Interface Definition Language: linguagem de definição de interface de objeto
independente da linguagem usada na implementação do mesmo.
IIOP – Internet Inter-ORB Protocol: protocolo de comunicação que permite o acesso de
recursos WWW a partir de aplicações CORBA e vice-versa.
Integração: combinar partes de forma que elas trabalhem juntas ou formem um todo.
Interoperabilidade: capacidade de sistemas comunicarem uns com os outros, trocando e
usando informações que incluem conteúdos, formatos e semânticas.
J2EE – Java to Enterprise Edition: plataforma de desenvolvimento de aplicações
empresariais, baseada na linguagem de programação Java da Sun Microsystems.
J2EE Connector: tecnologia desenvolvida pela Sun Microsystem, pertencente à plataforma
J2EE, que permite a integração de sistemas desenvolvidos em Java com sistemas legados,
ERPs e bancos de dados não relacionais.
161
JMS – Java Messaging Service: Serviço de Mensagens Java que possibilita a troca de
mensagens em Sistemas Distribuídos. Pode ser utilizado diretamente numa aplicação
corporativa ou por meio de um tipo de EJB chamado Message-Driven-Bean.
JNDI – Java Naming and Directory Interface: interfaces de aplicação Java para acesso a
Serviços de Nomes e Diretórios.
JTA – Java Transaction API: interface de programação de aplicações que possibilita a
implementação de controles de transações, que se resume no agrupamento de múltiplas
operações numa simples operação atômica, em que ou todas, ou nenhuma operação é
realizada. Essa tecnologia é utilizada para o desenvolvimento de sistemas distribuídos.
JTS – Java Transaction Service: é um serviço de gerenciamento de transações que suporta
JTA e faz uso de IIOP para a comunicação entre instâncias remotas de um serviço. Como
JTA, também é utilizado para o desenvolvimento de sistemas distribuídos.
JVM – Java Virtual Machine: é uma máquina computacional abstrata responsável pela
execução de softwares desenvolvidos em Java, propiciando independência de hardware e
Sistema Operacional.
JDK – Java Development Kit: ambiente de desenvolvimento de software para a criação de
aplicativos escritos na linguagem de programação Java.
Meet-in-the-Middle: abordagem para desenvolvimento de serviços Web, utilizada pelo
Provedor, cuja aplicação e o serviço Web já existem, realizando a integração de ambos.
Middleware: Produto de software que funciona como uma "camada" (layer) de conversão ou
tradução. Geralmente é fornecido por terceiros e reutilizado na implementação de outros
softwares, sendo o responsável por conectar tecnologias.
MIME - Multipurpose Internet Mail Extension: protocolo da Internet utilizado para transporte
de arquivos binários (imagens, sons ou vídeos, por exemplo) atachados em mensagens.
Namespace: artifício que representa uma forma de ser resolver conflitos de nomes de
elementos e atributos em documentos baseados em XML.
162
ORB – Object Request Broker: barramento de objetos que permite a comunicação entre
objetos por meio da chamada de métodos e recebimento de respostas, de forma transparente e
independente da localização dos objetos (local ou remota).
Parser: São interfaces de programação de aplicativos usadas para criação de unidades de
programas capazes de converter documentos XML em objetos e vice-versa.
QoS – Quality of Service: Conjunto mínimo de qualidade que se deseja garantir a um
determinado serviço.
RMI – Remote Method Invocation: protocolo de comunicação de objetos remotos Java.
RUP – Rational Unified Process: processo de desenvolvimento de software proposto pela
Rational Software Corporation que visa a redução de riscos no desenvolvimento de projetos
de software.
Service Proxy: unidade de programa que contém todo o código que é requerido para acessar e
invocar um Serviço Web.
Skeleton: objeto delegado, ativado do lado de um servidor num processo de chamada remota.
O objeto skeleton faz um par com o objeto delegado stub. O skeleton recebe a solicitação de
execução de um método e seus argumentos, ativa a implementação do objeto servidor, obtém
a resposta e a retorna ao stub.
SOAP – Simple Object Access Protocol: Protocolo simples de acesso a objetos baseado em
XML que utiliza para transporte o protocolo HTTP ou outro, sendo utilizado na comunicação
entre serviços Web.
Socket: são interfaces que fazem as ligações entre as conexões originadas do sistema
operacional e dos processos dos usuários.
Stakeholders: são indivíduos ou organizações que estão ativamente envolvidos no projeto ou
cujos interesses podem ser positiva ou negativamente afetados pelos resultados do projeto.
Stub: é o objeto delegado do objeto servidor (skeleton) na máquina cliente. O stub obtém
solicitações de execução de métodos e seus argumentos e os repassa ao objeto servidor.
Token: ficha usada para controle de sincronização em sistemas distribuídos.
163
Top-Down: abordagem para desenvolvimento de serviços Web, utilizada pelo Provedor.
Refere-se ao desenvolvimento de uma aplicação a partir de uma interface de serviço Web
existente.
tModel – Technical Model: Unidade de registro de um serviço Web num Serviço de Registros
UDDI.
UDDI – Universal Description, Discover and Integration: serviço de registro de entidades de
negócios e serviços de negócio, oferecidos por essas entidades de negócio. Permite a
descrição, descoberta e integração de serviços Web.
UML - Unified Modeling Language: é uma linguagem para a Modelagem Visual de sistemas,
composta de diversos diagramas que permitem visões diferenciadas do projeto de software,
apresentando níveis de abstração diferentes.
URI – Uniforme Resource Identifier: é uma string compacta usada para identificar um recurso
abstrato ou físico na web: documentos, imagens, arquivos para download, serviços, e outros
recursos.
URL – Uniform Resource Locator: é um tipo de URI, uma sintaxe e semântica de informação
formalizada para localização e acesso de recursos na Internet.
WBS – Work Breakdown Structure: Estrutura Analítica do Projeto – EAP: refere-se a um
agrupamento de componentes do projeto que organiza e define seu escopo total. É orientada
para a elaboração de subprodutos denominados deliverables.
Web: referenciada também como WWW (World Wide Web), é a rede mundial de
computadores, ou Internet.
Web browser- Navegador Web: software utilizado para navegação na Internet, sobre o qual
são projetadas as interfaces entre o usuário e os diversos recursos disponibilizados na rede.
Web Service: serviço disponibilizado na web na forma de interfaces de software, permitindo a
interoperabilidade de sistemas.
WSDL – Web Service Description Language: linguagem de descrição de serviços Web
utilizada para fornecer detalhes sobre o serviço disponibilizado, permitindo a implementação
de sistemas que interajam como o serviço.
164
WS4PM – Web Services For Project Management: Serviços Web para a gestão de projetos.
Solução tecnológica baseada em serviços Web que visa a interoperabilidade de softwares de
gestão de projetos, propiciando o gerenciamento integrado de projetos relacionados.
XML – eXtensible Markup Language: linguagem de marcação extensível, baseada em texto,
utilizada para representar estruturas de dados e instâncias de informação.
FOLHA DE REGISTRO DO DOCUMENTO
1.
CLASSIFICAÇÃO/TIPO
TM
5.
2.
DATA
3.
DOCUMENTO N°
4.
N° DE PÁGINAS
02 de março de 2004 CTA/ITA-IEC/TM-010/2004
295
TÍTULO E SUBTÍTULO:
Um Modelo de Interoperabilidade para Softwares de Gestão de Projetos
6.
AUTOR(ES):
7.
INSTITUIÇÃO(ÕES)/ÓRGÃO(S) INTERNO(S)/DIVISÃO(ÕES):
Instituto Tecnológico de Aeronáutica / Divisão de Ciência da Computação – ITA/IEC
8.
PALAVRAS-CHAVE SUGERIDAS PELO AUTOR:
Interoperabilidade de Software, Serviços Web, Gestão de Projetos em Parceria, Projetos de Larga Escala
9.PALAVRAS-CHAVE RESULTANTES DE INDEXAÇÃO:
Desenvolvimento de software; Gerenciamento de projetos; Administração de produção; Redes de comunicação;
Internet; Relações de cooperação; Empresas; Computação; Administração.
10.
APRESENTAÇÃO:
X Nacional
Internacional
Instituto Tecnológico de Aeronáutica, ITA. São José dos Campos, 2003, 295 páginas
11.
RESUMO:
Está se tornando comum que o desenvolvimento de produtos ou serviços seja realizado
conjuntamente por empresas parceiras ou contratadas, que podem estar situadas em diferentes partes do mundo.
Em geral, para entregar o produto ou serviço especificado dentro do prazo e com o custo planejado, a disciplina
de gerência de projetos tem sido empregada.
Esta disciplina consiste de grupos de processos para o inicio, planejamento, controle, execução e o
encerramento de atividades. Geralmente as empresas utilizam ferramentas computacionais para a realização do
trabalho de gerenciamento e é comum encontrar parceiras de projeto e contratadas utilizando ferramentas
distintas que possuem pouco ou nenhum recurso de integração. Isto resulta em dificuldades na gestão integrada
do projeto e de seus subprojetos, contribuindo para um controle ineficiente, altos custos e descumprimento de
prazos.
Este trabalho endereça os aspectos de interoperabilidade entre softwares de gestão de projetos,
envolvendo um levantamento dos requisitos de comunicação e integração, com base na metodologia de gestão
proposta pelo PMBOK, para propor um modelo de solução em que estes softwares exponham funcionalidades
que possam ser invocadas remotamente, para a realização de processamentos e troca de dados entre empresas
parceiras de projeto.
A tecnologia de serviços Web foi investigada como alternativa para a implementação da solução
proposta devido ao fato de ser baseada em padrões abertos e tecnologias WWW disponíveis.
A especificação de requisitos foi realizada com base nos conceitos do PMBOK e em entrevistas
com a equipe de gerenciamento de projetos do Programa EMBRAER 170/190. Estes projetos são desenvolvidos
em parceria com várias empresas, e cada uma delas é responsável pelo desenvolvimento de uma ou mais partes,
que compõem os produtos desses projetos.
O modelo de solução e a tecnologia de serviços Web foram testados e validados por meio da
implementação de dois protótipos de software de gestão de projetos, concebidos a partir das tecnologias Java e
.NET. Eles representam softwares de gestão de projetos de fabricantes diferentes que trocam dados, propiciando
a aplicação da técnica Análise de Valor Agregado em projetos relacionados.
12.
GRAU DE SIGILO:
(X ) OSTENSIVO ( ) RESERVADO
( ) CONFIDENCIAL
( ) SECRETO
Tese apresentada à Divisão de Pós-Graduação do Instituto Tecnológico de Aeronáutica como
parte dos requisitos para obtenção do título de Mestre em Ciência no Curso de Pós-Graduação
em Engenharia Eletrônica e Computação na Área de Informática.
para
Volume 2
Tese aprovada em sua versão final pelos abaixo assinados.
Orientador
Prof. Dr. Homero Santiago Maciel
Chefe da Divisão de Pós-Graduação
Campo Montenegro
São José dos Campos, SP - Brasil
2003
para
Composição da Banca Examinadora:
Prof. Dr. Edgar Toshiro Yano
Prof. Dr. Clovis Torres Fernandes
Prof. Dr. José Henrique de Sousa Damiani
Prof. Dr. Jorge Luis Risco Becerra
Presidente – ITA
Orientador – ITA
Membro – ITA
Membro – ITA
Membro Externo – USP-Poli
ITA
Agradecimentos........................................................................................................................................ ii
Resumo ................................................................................................................................................... iii
Abstract ................................................................................................................................................... iv
Lista de Ilustrações ............................................................................................................................... viii
Lista de Tabelas .......................................................................................................................................x
Lista de Abreviaturas e Siglas................................................................................................................. xi
Capítulo I ....................................................................................................................1
Introdução................................................................................................................................................ 1
1.1
Motivação.............................................................................................................................................. 1
1.2
Objetivos ............................................................................................................................................... 2
1.3
Escopo do Trabalho ............................................................................................................................... 2
1.4
Resumo dos Próximos Capítulos ........................................................................................................... 3
Capítulo II ...................................................................................................................5
A Gestão de Projetos e Projetos de Larga Escala Envolvendo Empresas Parceiras ............................ 5
2.1
Definições e Conceitos da Gestão de Projetos....................................................................................... 5
2.1.1
Processos e Grupos de Processos de Projetos ............................................................................. 6
2.1.2
Envolvidos e Interessados no Projeto ......................................................................................... 8
2.1.3
As Áreas de Conhecimento do Gerenciamento de Projetos........................................................ 8
2.1.4
Estrutura Analítica de Projeto................................................................................................... 11
2.1.5
Relato do Desempenho de Projetos .......................................................................................... 12
2.2
Projetos de Larga Escala Envolvendo Empresas Parceiras ................................................................. 21
2.3
Um exemplo de Projeto de Larga Escala que Envolve Parceiros ........................................................ 23
2.4
Ferramentas Computacionais de Apoio à Gestão de Projetos ............................................................. 27
2.4.1
Ferramentas de Apoio à Especificação, Análise e Controle de Requisitos............................... 28
2.4.2
Ferramentas de Apoio ao Planejamento e Monitoramento de Projetos .................................... 29
2.4.3
Ferramentas de Apoio à Comunicação e ao Trabalho Cooperativo .......................................... 32
2.4.4
Ferramentas de Apoio à Gestão Empresarial ............................................................................ 34
2.4.5
Ferramentas de Apoio ao Controle de Versões e Gerência de Configuração ........................... 35
2.5
Resumo do Capítulo e Alguns Comentários........................................................................................ 36
Capítulo III ................................................................................................................37
O Software como Serviço...................................................................................................................... 37
3.1
Sistemas Distribuídos e os Serviços Web............................................................................................ 37
3.2
Conceituação de Serviços Web ........................................................................................................... 40
3.3
Tecnologias de Suporte aos Serviços Web .......................................................................................... 43
3.3.1
A Linguagem de Marcação Estendida - XML .......................................................................... 45
3.3.2
O Protocolo de Comunicação SOAP ........................................................................................ 48
3.3.3
A Linguagem de Descrição de Serviços Web – WSDL............................................................ 51
3.3.4
O Serviço de Publicação de Serviços Web – UDDI ................................................................ 57
3.4
Arquiteturas de Aplicativos e Interação de Serviços Web................................................................... 61
3.5
A Arquitetura Global para Serviços Web em XML – GXA................................................................ 66
3.5.1
Segurança em Serviços Web..................................................................................................... 68
3.5.2
Transações em Serviços Web ................................................................................................... 69
3.5.3
Coordenação de Processos de Serviços Web ............................................................................ 69
3.5.4
Mensagens Confiáveis entre Serviços Web .............................................................................. 70
3.5.5
Roteamento e Referência de Serviços Web .............................................................................. 70
3.5.6
Anexos em Mensagens de Serviços Web.................................................................................. 71
3.6
Desempenho de Serviços Web ............................................................................................................ 72
3.7
Conceitos no Desenvolvimento de Serviços Web ............................................................................... 74
3.7.1
Fases do Ciclo de Desenvolvimento de Serviços Web ............................................................. 74
3.7.2
Abordagens para o Desenvolvimento de Serviços Web ........................................................... 76
3.8
Plataformas de Desenvolvimento de Serviços Web ............................................................................ 78
3.9
Serviços Web na Plataforma J2EE ...................................................................................................... 79
3.9.1
O Padrão ebXML...................................................................................................................... 81
3.9.2
Servlets ..................................................................................................................................... 82
3.9.3
Java Server Pages...................................................................................................................... 82
3.9.4
Java Beans e Enterprise Java Beans.......................................................................................... 83
3.9.5
Conectores J2EE ....................................................................................................................... 85
3.10
Serviços Web na Plataforma Microsoft .NET ..................................................................................... 86
3.11
Resumo do Capítulo e Resultados Obtidos.......................................................................................... 88
Capítulo IV................................................................................................................90
Uma Proposta de Solução de Interoperabilidade para a Gestão de Projetos de Larga Escala
Envolvendo Empresas Parceiras .......................................................................................................... 90
4.1
Utilização de um Processo de Desenvolvimento de Software ............................................................. 90
4.2
Uma Visão do Problema e o Modelo de Solução Proposto ................................................................. 96
4.3
Um Plano para o Gerenciamento de Requisitos ................................................................................ 100
4.4
Especificação de Requisitos Funcionais ............................................................................................ 101
4.5
Especificação de Requisitos Não Funcionais .................................................................................... 105
4.6
Capítulo V...............................................................................................................107
Protótipos de Software de Gestão de Projetos Interoperáveis ........................................................... 107
5.1
Finalidade e Escopo dos Protótipos................................................................................................... 107
5.2
Principais Interfaces de Usuário ........................................................................................................ 110
5.3
Detalhes da Arquitetura ..................................................................................................................... 120
5.3.1
A Camada de Acesso a Dados (persistence) ........................................................................... 123
5.3.2
A Camada de Entidades de Negócio (business)...................................................................... 126
5.3.3
A Camada de Controle de Fluxos de Casos de Uso (control) ................................................. 129
5.3.4
A Camada de Serviços (services)............................................................................................ 131
5.3.5
A Camada de Apresentação (presentation) ............................................................................. 134
5.4
Detalhes da Implementação do Serviço Web .................................................................................... 136
5.4.1
O Serviço Web de Relato de Desempenho ............................................................................. 137
5.4.2
Consumidores do Serviço Web de Relato de Desempenho .................................................... 139
5.5
Cenário de Testes .............................................................................................................................. 141
5.6
Capítulo VI..............................................................................................................151
Conclusões, Contribuições e Sugestões de Trabalhos Futuros ......................................................... 151
6.1
Conclusões......................................................................................................................................... 151
6.2
Contribuições..................................................................................................................................... 152
6.3
Sugestões de Trabalhos Futuros ........................................................................................................ 152
Referências Bibliográficas ...................................................................................154
Glossário................................................................................................................158
Apêndice 1
Visão (Conforme Modelo do RUP)...................................................................................................... 165
Apêndice 2
Glossário (Conforme Modelo do RUP) ............................................................................................... 176
Apêndice 3
Plano de Gerenciamento de Requisitos (Conforme Modelo do RUP)................................................ 183
Apêndice 4
Considerações e Requisitos de Serviços Web para Projetos de Larga Escala Envolvendo Empresas
Parceiras ............................................................................................................................................. 193
Apêndice 5
Especificações Suplementares (Conforme Modelo do RUP) ............................................................. 221
Apêndice 6
Relação Analítica de Requisitos.......................................................................................................... 227
ITA - Instituto Tecnológico de Aeronáutica
WS4PM - Serviços Web para Gestão de Projetos
Visão
Conforme Modelo do RUP
Versão 1.2
Apêndice 1
WS4PM - Visão
Versão
Histórico da Revisão
Descrição
13/02/2003
1.0
Versão Inicial do Documento de Visão
Osvandre
21/03/2003
1.1
Revisão do Orientador
Celso Hirata
25/09/2003
1.2
Versão final
Osvandre
Data
Autor
166
WS4PM - Serviços Web Aplicáveis à Gestão de Projetos
Visão
Apêndice 1
Versão:
1.2
Data: 25/09/2003
Índice Analítico
1.
Introdução
1.1
Referências
1.2
Siglas e Acrônimos
1.3
Visão Geral deste Documento
168
168
168
168
2.
Posicionamento
2.1
Descrição do Problema
2.2
Sentença de Posição da Solução
169
169
169
3.
Descrições dos Envolvidos e Interessados
3.1
Resumo dos Envolvidos e Interessados
3.2
Ambiente dos Usuários
3.3
Resumo das Principais Necessidades dos Envolvidos e Interessados
169
170
171
172
4.
Visão Geral da Solução Tecnológica Proposta
4.1
Perspectiva
4.2
Suposições e Dependências
173
174
174
5.
Recursos do Produto
5.1
Interoperabilidade de Softwares de Gestão de Projetos
5.2
Independência de Plataforma
5.3
Acessibilidade
5.4
Conformidade com Padrões
5.5
Facilidades para a Estabelecimento de Parcerias de Projetos.
5.6
Confiabilidade e Segurança
5.7
Suporte às Áreas de Conhecimento da Gestão de Projetos
5.8
Suporte aos Grupos de Processos da Gestão de Projetos
174
174
174
174
174
174
174
174
175
6.
Outros Requisitos do Produto
175
IEC – Divisão de Ciência da
Computação
©ITA - Instituto Tecnológico de
Aeronáutica, 2003
167
Visão
Apêndice 1
Versão:
1.2
Data: 25/09/2003
Visão
1. Introdução
Este documento de Visão foi elaborado com base no Modelo de Documento de Visão proposto pelo
Processo Unificado Rational – PUR (Rational Unified Process - RUP) [1] e é parte de um conjunto de artefatos
gerados para a documentação do desenvolvimento de Serviços Web para a Gestão de Projetos (Web Services for
Project Management – WS4PM).
A finalidade deste documento é coletar, analisar e definir as necessidades e características gerais que
devem ser endereçadas nos WS4PM. Ele enfoca os recursos que os envolvidos e interessados precisam e mostra
porque essas necessidades existem. Os detalhes de como os WS4PM atendem a essas necessidades são descritos
em Especificações Suplementares e de Caso de Uso.
Os WS4PM visam a interoperabilidade entre Softwares de Gestão de Projetos de forma a atender a
necessidades específicas do ambiente de projetos que envolvem parceiros.
1.1 Referências
Os seguintes documentos são mencionados neste Documento de Visão e contribuíram para sua
elaboração:
[1] RUP – Rational Unified Process v2002.05.00, Copyright © Rational Software Corporation.
[2] MARTINS, Osvandre Alves - Considerações e Requisitos de Serviços Web para Projetos de Larga
Escala Envolvendo Empresas Parceiras – Documento desenvolvido com base no PMBOK e numa
pesquisa de campo realizada na Empresa Brasileira de Aeronáutica – EMBRAER.
[3] PMI – Project Management Institute – PMBOK 2000 - A Guide to the Project Management Body
of Knowledge – PMBOK Guide, 2000.
1.2 Siglas e Acrônimos
Vide documento Glossário.
1.3 Visão Geral deste Documento
Este documento contém o posicionamento da Solução Tecnológica a ser gerada a partir da
Especificação de Serviços Web para a Gestão de Projetos, os WS4PM, bem como uma análise dos envolvidos e
interessados (stakeholders), e uma lista de características que eles deverão endereçar. Esses recursos foram
definidos a partir de solicitações dos envolvidos e interessados na Gestão de Projetos de Larga Escala que
Envolvem Parceiros.
Os parágrafos que possuem os identificadores STRQ e FEAT indicam que estes foram rastreados para
a ferramenta utilizada para auxiliar as atividades referentes à análise e gerenciamento de requisitos, o Rational
RequisitePro.
Computação
Aeronáutica, 2003
168
Visão
Apêndice 1
Versão:
1.2
Data: 25/09/2003
2. Posicionamento
Esta seção apresenta um resumo do problema que está sendo resolvido e também uma sentença de
posição da solução, comunicando o objetivo da mesma e sua importância para todo o pessoal envolvido.
2.1 Descrição do Problema
O problema
ausência da interoperabilidade de softwares de gestão de projetos,
concebidos a partir de tecnologias distintas.
Afeta
empresas que desenvolvem projetos de larga escala envolvendo
empresas parceiras e contratadas.
O seu impacto é
que existe um grande volume de retrabalho na execução das
atividades dos Processos de Gestão desses projetos, reduzindo sua
eficiência.
Uma boa solução seria
dotar os softwares de gestão de projetos de um conjunto de serviços
Web que os permita interoperar por meio da Internet ou de uma
intranet, trocando dados e realizando processamentos.
2.2 Sentença de Posição da Solução
Para
empresas que desenvolvem Projetos de Larga Escala que Envolvem
Parceiros
Quem
Necessitar realizar a iniciação, o planejamento, o controle e o
encerramento de seus projetos com parceiros, de forma integrada
Os WS4PM (Web
Services For Project
Management)
são um grupo de serviços Web
Que
Propiciam a interoperabilidade entre Softwares de Gestão de Projetos
Diferente de
O estado atual, onde a Gestão de Projetos de Larga Escala que
Envolvem Parceiros ocorre de forma isolada entre as partes, exigindo
retrabalho para a integração de informações pertinentes
Os WS4PM
Quando devidamente implementados em Softwares de Gestão de
Projetos e publicados num servidor de registros (UDDI) representam
uma economia de tempo e esforço na integração dos processos
gerenciais de parceiros projetos.
3. Descrições dos Envolvidos e Interessados
Para fornecer, de maneira eficiente, produtos e serviços que atendam às reais necessidades dos
envolvidos e interessados (stakeholders), é necessário identificar e considerar todos eles como parte do processo
de Modelagem de Requisitos. É necessário também identificar os usuários do sistema e assegurar que a
comunidade de envolvidos os represente adequadamente. Esta seção fornece um perfil dos envolvidos e
possíveis usuários dos WS4PM, e dos principais problemas que, de acordo com o ponto de vista deles, poderão
ser abordados pela solução proposta. Na subsessão 3.3 são descritas as solicitações dos envolvidos e
interessados. Geralmente elas são capturadas num artefato individual de solicitações dos envolvidos, mas neste
caso, optou-se por especificá-las aqui.
Computação
Aeronáutica, 2003
169
Visão
Apêndice 1
Versão:
1.2
Data: 25/09/2003
3.1 Resumo dos Envolvidos e Interessados
Há uma série de envolvidos e interessados no desenvolvimento da interoperabilidade entre Softwares
de Gestão de Projetos e nem todos eles são usuários finais. A lista a seguir é um resumo desses envolvidos e
interessados que, de alguma forma, são afetados pelo desenvolvimento dos WS4PM.
Nome
Descrição
Responsabilidades
Executivos
É a alta administração, tanto da
Empresa Líder do Projeto,
quanto das Empresas Parceiras
do Projeto.
Tomam decisões em alto nível, a
partir de informações resumidas, do
andamento dos projetos.
Membros de Equipes
Funcionais
Refere-se ao corpo de
profissionais que desempenham
tarefas nas diversas áreas
funcionais das organizações que
se relacionam com a área de
Gestão de Projetos.
Realizam ações de suporte, em
âmbito funcional, durante o
andamento de projetos.
Membros da Equipe de
Gestão de Programas
São profissionais que executam
a gestão, em nível mais alto, de
um conjunto de projetos, que
representam um Programa.
Coordenam, em alto nível, um
conjunto de projetos
Gestão de Integração
em Projetos
Representam profissionais
encarregados de garantir a
integração dos processos da
Desenvolvem Planos de Projetos,
executam esses planos e realizam o
Controle Integrado de Mudanças.
Escopo de Projetos
Profissionais encarregados de
realizar ações que definem e
controlam o escopo de projetos.
Autorizam o projeto, planejando,
detalhando, verificando e
controlando alterações no escopo
visando assegurar que o projeto
inclua todo o trabalho necessário e
suficiente.
Gestão Prazo de
Projetos
Profissionais encarregados de
realizar ações relacionadas ao
prazo, em termos de tempo,
necessário para a execução de
projetos.
Definem, sequenciam e estimam a
duração das atividades. Com base
nisso, Desenvolvem e controlam o
cronograma de projetos.
Gestão de Custos de
Projetos
Profissionais que realizam ações
que visam assegurar que o
projeto será concluído dentro do
orçamento aprovado.
Planejam recursos, estimam e
orçam e controlam os custos de
projetos.
Gestão de Qualidade
em Projetos
Profissionais responsáveis pela
Gestão da Qualidade em
projetos.
Executam o planejamento e
controle da qualidade visando
garanti-la ao longo de projetos.
Gestão de Recursos
Humanos de Projetos
Profissionais destinados à
execução de processos que
visam tornar mais efetivo o uso
de recursos humanos envolvidos
em projetos.
Realizam o Planejamento
Organizacional, a montagem e o
desenvolvimento de equipes de
projetos.
Computação
Aeronáutica, 2003
170
Visão
Apêndice 1
Versão:
1.2
Data: 25/09/2003
Gestão da
Comunicação em
Projetos
Conjunto de profissionais que
executam processos que visam
garantir e regular a apropriada
geração,coleta, disseminação,
armazenamento e descarte de
informações do projeto.
Realizam o planejamento das
comunicações, distribuição das
informações, o relato de
desempenho do projeto e o
encerramento administrativo de
projetos.
Gestão de Riscos em
Projetos
Grupo de profissionais voltados
ao processo sistemático de
identificar, analisar e responder
a riscos em projetos.
Realizam o planejamento da
gerência de riscos, a identificação, a
análise qualitativa e quantitativa de
riscos, o planejamento de respostas,
controle e monitoração de riscos.
Gestão de Aquisições
em Projetos
Grupo de profissionais que
executam processos necessários
à obtenção de bens e serviços
externos à organização
executora do projeto.
Realizam o planejamento e
preparação de aquisições, a
obtenção de propostas , seleção de
fornecedores, a administração e
encerramento de contratos.
Membro Equipe de
Desenvolvimento de
Softwares
Pessoas diretamente envolvidas
com o processo de
desenvolvimento de software
das organizações.
Executam processos ligados à
análise e desenvolvimento de
sistemas de software para apoio às
áreas funcionais e à área de Gestão
de Projetos das empresas.
3.2 Ambiente dos Usuários
O ambiente dos usuários de WS4PM é mesmo dos usuários de Software de Gestão de Projetos uma
vez que as implementações desses serviços representam componentes que podem ser desenvolvidos e
integrados a esses produtos. Como exemplo, pode-se citar os Escritórios de Programas e os Escritórios de
Projetos de empresas que desenvolvem Projetos de Larga Escala e que contam com o envolvimento de
empresas parceiras.
Diversas plataformas de sistemas são utilizadas nesse ambiente, uma vez que os parceiros de projetos
geralmente se encontram em localidades distintas com estruturas e ambientes distintos, não havendo
padronizações.
Alguns Softwares de Gestão de Projetos, com recursos de Ambientes Cooperativos através da Internet,
já são uma realidade e oferecem uma série de ferramentas que resolvem, principalmente, o problema de
dispersão geográfica entre as empresas parceiras. Além desses, são utilizados diversos outros, como: Softwares
de Gestão Empresarial; Planilhas Eletrônicas; Editores de Texto; dentre outros. Esses softwares apoiam as
Equipes Funcionais e de Gestão de Projetos no desempenho de suas funções.
Os WS4PM não focam a interoperabilidade de softwares, que não sejam aqueles destinados à Gestão
de Projetos e que são utilizados por empresas distintas, possibilitando a integração desses sistemas na
modalidade B2Bi (Business To Business Integration).
Computação
Aeronáutica, 2003
171
Visão
Apêndice 1
Versão:
1.2
Data: 25/09/2003
3.3 Resumo das Principais Necessidades dos Envolvidos e Interessados
Nesta seção são listados os principais problemas endereçados pelos envolvidos e interessados em
relação à utilização de Softwares de Gestão de Projetos, tendo como base, os estudos e pesquisas realizadas.
Problema
Causas
Solução Atual
Soluções
Propostas
A pouca ou inexistente
interoperabilidade entre os
Softwares de Gestão de
Projetos utilizados por
parceiros.
Grande número de
Fornecedores de
Projetos e pouca
preocupação com a
integração de seu
produto a outros do
mesmo seguimento.
Construção de soluções
proprietárias, como Sistemas
de Mensagens, Ambientes
Cooperativos que, em sua
maioria, exigem retrabalho
por parte das equipes de
projeto.
O desenvolvimento de
serviços Web que
permitam a
interoperabilidade entre
Projetos.
A pouca ou inexistente
integração de seus
Projetos com as demais
ferramentas que apoiam o
processo.
Produtos de software
desenvolvidos ao longo
do tempo para fins
específicos, não levando
em consideração
aspectos de integração
com outros sistemas.
Utilização de recursos de
importação e exportação de
dados, e até redigitação de
informações.
Especificar um
conjunto de serviços
que permitam a
Integração (EAI) de
Projetos com outras
ferramentas de
software utilizadas em
Áreas Funcionais da
empresa.
O alto volume de retrabalho
quanto ao registro e
processamento de
informações dando margem
a inconsistências e
incompletezas.
Diferentes ferramentas
de software sendo
utilizadas para auxílio à
execução dos processos.
Checagens de consistência
manuais ou semiautomáticas.
A implementação da
os sistemas com
recursos de gatilhos
que replicam
informações e
executam
processamentos de
forma automática.
Dificuldades no processo de
inicialização de parcerias,
quanto à utilização de
ferramentas,
estabelecimento de padrões,
documentos e técnicas.
Grande diversidade de
ferramentas disponíveis,
ausência de padronização
de processos,
documentos e técnicas.
Trabalho intenso e dirigido,
geralmente com imposições
de padrões feitas pela
Empresa Líder do Projeto.
O desenvolvimento da
os Softwares de Gestão
de Projetos,
contribuindo para a
definição de padrões,
em termos de
comunicação de
informações entre os
envolvidos.
É essencial entender a importância relativa atribuída pelo envolvido ou interessado à resolução de cada
problema. Técnicas de ordenação e votação cumulativa indicam os problemas que devem ser resolvidos versus
problemas que eles gostariam que fossem resolvidos.
A tabela a seguir resume as principais necessidades dos envolvidos ou usuários que devem ser
consideradas nos WS4PM. Elas foram definidas a partir do documento “Considerações e Requisitos de Serviços
Web para Projetos de Larga Escala que Envolvem Parceiros” desenvolvido com base no PMBOK e numa
pesquisa de campo realizada na Empresa Brasileira de Aeronáutica S/A - EMBRAER.
Computação
Aeronáutica, 2003
172
Visão
Apêndice 1
Versão:
1.2
Data: 25/09/2003
Principais Necessidades dos Envolvidos e Interessados
STRQ1 É necessário que se provenha interoperabilidade quanto a execução dos processos relacionados às 9 (nove)
Áreas de Conhecimento da Gestão de Projetos, definidas pelo PMI , que são:
1 - STRQ1.1 Gestão da Integração ;
2 - STRQ1.2 Gestão do Escopo ;
3 - STRQ1.3 Gestão de Prazos ;
4 - STRQ1.4 Gestão de Custos ;
5 - STRQ1.5 Gestão de Qualidade ;
6 - STRQ1.6 Gestão de Recursos Humanos ;
7 - STRQ1.7 Gestão da Comunicação ;
8 – STRQ1.8 Gestão de Riscos ; e
9 – STRQ1.9 Gestão de Aquisições .
STRQ2 É necessário que se provenha interoperabilidade na execução dos processos contantes nos 5 (cinco) Grupos
de Processos da Gestão de Projetos, definidos pelo PMI , que são:
1 – STRQ2.1 Processos de Iniciação ;
2 – STRQ2.2 Processos de Planejamento ;
3 – STRQ2.3 Processos de Execução ;
4 – STRQ2.4 Processos de Controle ; e
5 – STRQ2.5 Processos de Encerramento .
4. Visão Geral da Solução Tecnológica Proposta
Os WS4PM visam a interoperabilidade de produtos de Softwares de Gestão de Projetos. Esses serviços
Web são aplicações que residem nas fronteiras das organizações, propiciando a interoperabilidade entre
sistemas desenvolvidos e suportados por tecnologias distintas ou não, e que se encontram hospedados em locais
remotos. A figura a seguir fornece uma visão geral da solução proposta.
Empresa Líder do Projeto
Software de
Empresa Parceira do Projeto
Provedor
Consumidor
WS4PM
WS4PM
Gestão de Projetos
A
Software de
Gestão de Projetos
Consumidor
Provedor
WS4PM
WS4PM
B
Um determinado usuário do “Software de Gestão de Projetos B”, ao registrar uma dada informação,
dispara uma “aplicação consumidora” que acessa remotamente um Serviço Web instalado na Empresa Líder do
Projeto, esse serviço interage com o “Software de Gestão de Projetos A” processando as informações, e se for o
caso, retornando resultados à Empresa Parceira do Projeto. O inverso pode ocorrer para alguns serviços, onde a
Empresa Líder do Projeto é consumidora de serviços providos pela parceira.
173
Computação
Aeronáutica, 2003
Visão
Apêndice 1
Versão:
1.2
Data: 25/09/2003
4.1 Perspectiva
Acredita-se que os WS4PM, quando devidamente implementados, venham a contribuir muito para a
Gestão de Projetos de Larga Escala que Envolvem Parceiros, aumentando a sinergia entre as Empresas
Parceiras e a Líder do Projeto, simplificando a execução dos diversos processos que elas têm de executar para
garantirem o retorno sobre seus investimentos em projetos.
4.2 Suposições e Dependências
Uma vez que os WS4PM visam a interoperabilidade entre Softwares de Gestão de Projetos distintos ou
não, e que estão instalados e executando em localidades remotas, para que esses serviços sejam eficientes e
eficazes, cabe a cada fabricante de Software de Gestão de Projetos especificar detalhadamente e implementar
seus WS4PM, verificando a melhor tecnologia, dentre aquelas que suportam a construção de serviços Web.
Uma série de requisitos, como por exemplo, os relacionados a segurança de informação e controle de
transações podem ser atendidos com o uso de especificações como a WS-Security e a WS-Transaction
constantes na GXA (Global XML Architecture), porém pode-se afirmar que nesses aspectos existe uma
dependência dessas especificações, por parte dos WS4PM.
5. Recursos do Produto
Esta seção apresenta os principais recursos e características endereçados nos WS4PM.
5.1 Interoperabilidade de Softwares de Gestão de Projetos
Os WS4PM propiciam a interoperabilidade de Softwares de Gestão de Projetos auxiliando equipes de
gerenciamento de Projetos de Larga Escala que Envolvem Parceiros, no desempenho de suas funções.
5.2 Independência de Plataforma
FEAT8 Os WS4PM, por se basearem na tecnologia de serviços Web, podem ser acessados por
aplicações desenvolvidas em plataformas diferentes daquela que foi utilizada para implementá-los.
5.3 Acessibilidade
FEAT9 O uso da tecnologia de serviços Web permite que os WS4PM sejam acessados através da rede
mundial de computadores (Internet).
5.4 Conformidade com Padrões
FEAT10 Os WS4PM são desenvolvidos conforme os padrões estabelecidos e propostos pela W3C
(World Wide Web Consortium) e WS-I (Web Services Interoperability).
5.5 Facilidades para a Estabelecimento de Parcerias de Projetos.
FEAT11 Os WS4PM de cada empresa podem ser registrados em Servidores UDDI públicos ou
privados agilizando o processo de estabelecimento de parcerias de projetos, pois estas podem
conhecer, mutuamente, informações sobre seus negócios e os WS4PM que cada uma disponibiliza.
5.6 Confiabilidade e Segurança
FEAT12 Os WS4PM são desenvolvidos levando-se em consideração aspectos e confiabilidade e
segurança no processamento de informações.
5.7 Suporte às Áreas de Conhecimento da Gestão de Projetos
Os WS4PM endereçam funcionalidades referentes a todas as Áreas de Conhecimento da Gestão de
Projetos, definidas no PMBOK.
Computação
Aeronáutica, 2003
174
Visão
Apêndice 1
Versão:
1.2
Data: 25/09/2003
5.8 Suporte aos Grupos de Processos da Gestão de Projetos
Decorrente do recurso anterior, os WS4PM suportam, praticamente, todos os Processos da Gestão de
Projetos, definidos no PMBOK.
6. Outros Requisitos do Produto
Devido ao contexto em que se inserem os WS4PM, pode-se citar como requisitos adicionais,
principalmente, aqueles relacionados à disponibilidade, tolerância a falhas e usabilidade. Estes requisitos estão
descritos no documento de “Especificações Suplementares”.
Computação
Aeronáutica, 2003
175
Glossário
Conforme Modelo do RUP
Versão 1.2
Apêndice 2
Data
Versão
Descrição
Autor
03/03/2003
1.0
Rascunho inicial
Osvandre
23/03/2003
1.1
Celso Hirata/Osvandre
05/10/2003
1.2
Versão Final
Osvandre
177
Glossário
Apêndice 2
Versão:
1.2
Data: 05/10/2003
Índice Analítico
1.
Introdução
1.1
Finalidade
1.2
Escopo
1.3
Referências
1.4
Visão Geral
179
179
179
179
179
2.
Definições
2.1
Termos Relacionados à Gestão de Projetos
2.1.1 Áreas de Conhecimento da Gestão de Projetos
2.1.2 Empresas Parceiras
2.1.3 Empresa Proprietária
2.1.4 Envolvidos e Interessados
2.1.5 Escritórios de Programas
2.1.6 Escritórios de Projetos
2.1.7 PMBOK – Project Management Body of Knowledge
2.1.8 PMI – Project Management Institute
2.1.9 WBS – Work Breakdown Structure
2.2
Termos Técnicos de Informática
2.2.1 Artefato
2.2.2 B2Bi - BusinessTo Business Integration
2.2.3 Controle de Transação
2.2.4 CORBA- Common Object Request Broker Architecture
2.2.5 DCOM - Distributed Component Object Model
2.2.6 Documento de Visão
2.2.7 EAI- Enterprise Application Integration
2.2.8 Firewall
2.2.9 GXA – Global XML Architecture
2.2.10 Item de Rastreabilidade
2.2.11 HTTP – Hipertext Transfer Protocol
2.2.12 HTTPS - Hipertext Transfer Protocol Secure
2.2.13 Kerberos
2.2.14 Rastreabilidade
2.2.15 RMI- Remote Method Invocation
2.2.16 RUP – Rational Unified Process®
2.2.17 Serviço Web (Web Service)
2.2.18 SOAP – Simple Object Access Protocol
2.2.19 UDDI- Universal Description, Discover and Integration
2.2.20 UML - Unified Modeling Language
2.2.21 X.509 (Certificados Digitais)
2.2.22 W3C – World Wide Web Consortium
2.2.23 WS-I – Web Services Interoperability
2.2.24 WSDL - Web Service Description Language
2.2.25 WS-Security
2.2.26 WS-Transaction
179
179
179
179
179
179
180
180
180
180
180
180
180
180
180
180
180
180
181
181
181
181
181
181
181
181
181
181
181
181
182
182
182
182
182
182
182
182
Computação
Aeronáutica, 2003
178
Glossário
Apêndice 2
Versão:
1.2
Data: 05/10/2003
Glossário
1.
Introdução
Este documento de Glossário foi elaborado com base no Modelo de Glossário proposto pelo Processo
Unificado Rational – PUR (Rational Unified Process - RUP) [1] e é parte de um conjunto de artefatos gerados
para a documentação do desenvolvimento de Web Services para a Gestão de Projetos (Web Services for Project
Management – WS4PM).
1.1
Finalidade
A finalidade deste documento é definir a terminologia específica do domínio do problema endereçado,
explicando termos, que poderão ser desconhecidos para o leitor, e que constam em outros artefatos gerados pela
execução dos Processos de Engenharia de Software. Geralmente, este documento pode ser usado como um
dicionário de dados informal, capturando definições de dados para que as descrições de casos de uso e outros
documentos relacionados à construção dos WS4PM possam se concentrar no que o sistema deve fazer.
Este documento teve seu início e é atualizado frequentemente (quando necessário) durante o progresso
do projeto para desenvolvimento dos WS4PM.
1.2
Escopo
Os termos que serão inclusos nesse glossário serão somente aqueles que são citados nos demais
artefatos produzidos no levantamento e análise de requisitos para a implementação do WS4PM.
1.3
Referências
[2] PMI – Project Management Institute – PMBOK 2000 - A Guide to the Project Management Body of
Knowledge – PMBOK Guide, 2000.
1.4
Visão Geral
Os termos estão organizados em ordem alfabética dentro de dois grupos distintos, um referente aos
termos relacionados à Gestão de Projetos e outro que agrupa os termos relacionados à área de informática.
2.
Definições
2.1
Termos Relacionados à Gestão de Projetos
Esta seção contempla os termos citados nos documentos de especificação e gerência de requisitos
relacionados à Área de Gestão de Projetos.
2.1.1
Áreas de Conhecimento da Gestão de Projetos
Refere-se às nove áreas de conhecimento definidas pelo PMI, que agrupam funcionalidades com fins
específicos que executam processos dentro gestão de projetos.
2.1.2
Empresas Parceiras
Refere-se às empresas que possuem contratos de parceria e desenvolvem componentes que são
integrados ao produto de um projeto iniciado por uma empresa proprietária.
2.1.3
Empresa Proprietária
Refere-se à empresa mandatária de um projeto que conta com a participação de parceiros.
2.1.4
Envolvidos e Interessados
São todos aqueles que são afetados de forma direta ou indireta pelos resultados do projetos. O termo
Computação
Aeronáutica, 2003
179
Glossário
Apêndice 2
Versão:
1.2
Data: 05/10/2003
em inglês que os define é stakeholders.
2.1.5
Escritórios de Programas
Um conjunto de recursos materiais e humanos destinados à execução de processos relacionados à
Gestão de Programas. Os programas, no contexto de projetos, se referem a um conjunto de projetos.
2.1.6
Escritórios de Projetos
Um conjunto de recursos materiais e humanos destinados à gestão de Projetos específicos.
2.1.7
PMBOK – Project Management Body of Knowledge
Publicação elaborada pelo PMI – Project Management Institute que reúne os principais conceitos e
conhecimentos relacionados à Gestão de Projetos, obtidos através do consenso e da contribuição de
diversos profissionais e organizações relacionadas.
2.1.8
PMI – Project Management Institute
Organização não governamental dedicada à definição e divulgação as melhores práticas relacionadas à
2.1.9
WBS – Work Breakdown Structure
A tradução desse termo para português é Estrutura Analítica do Projeto – EAP. Refere-se a um
agrupamento de componentes do projeto que organiza e define seu escopo total. É orientada para a
elaboração de subprodutos denominados deliverables.
2.2
Termos Técnicos de Informática
Esta seção contempla os termos citados nos documentos de especificação e gerência de requisitos
relacionados à Área de Informática.
2.2.1
Artefato
Definidos pelo Processo Unicificado Rational (RUP), os artefatos são produtos de trabalho finais ou
intermediários produzidos e usados durante os projetos de software. Os artefatos são usados para
capturar e transmitir informações do projeto.
2.2.2
B2Bi - BusinessTo Business Integration
Modalidade de integração, através da Web, de sistemas heterogêneos ou não, realizada entre
organizações distintas no intuito de estreitar relacionamentos de parceria comercial.
2.2.3
Controle de Transação
É um método de coordenar um conjunto de alterações em bancos de dados visando garantir a
integridade e consistência dos dados manipulados.
2.2.4
CORBA- Common Object Request Broker Architecture
Arquitetura/tecnologia para a distribuição de objetos em ambientes distribuídos independente do
sistema operacional em uso.
2.2.5
DCOM - Distributed Component Object Model
Arquitetura/tecnologia proposta pela Microsoft como concorrente da CORBA na distribuição de
objetos em ambientes distribuídos Microsoft apenas.
2.2.6
Documento de Visão
Artefato que define a visão que os envolvidos têm do produto a ser desenvolvido, em termos das
necessidades e características mais importantes. Por conter uma descrição dos requisitos centrais
Computação
Aeronáutica, 2003
180
Glossário
Apêndice 2
Versão:
1.2
Data: 05/10/2003
pretendidos, ele proporciona a base contratual para requisitos técnicos mais detalhados.
2.2.7
EAI- Enterprise Application Integration
Modalidade de integração de sistemas computacionais heterogêneos, existentes dentro das fronteiras de
uma organização.
2.2.8
Firewall
Tecnologia utilizada para evitar que usuários não autorizados acessem recursos disponíveis em
servidores conectados à Internet.
2.2.9
GXA – Global XML Architecture
Architetura Global de XML é um conjunto de especificações construídas sobre XML, que são blocos
de construção para a implementação de Serviços Web dotados das habilidades como segurança,
controle de transações, mensagem confiável, dentre outras.
2.2.10 Item de Rastreabilidade
É qualquer elemento do projeto que necessite ser explicitamente rastreado a partir de outro item textual
ou de modelo, a fim de manter um controle das dependências entre eles.
2.2.11 HTTP – Hipertext Transfer Protocol
Protocolo de transporte utilizado para acesso a certos recursos na internet, geralmente públicos.
2.2.12 HTTPS - Hipertext Transfer Protocol Secure
Extensão do HTTP que provê segurança das informações quando de seu transporte, permitindo a
comunicação segura entre dois pontos da web.
2.2.13 Kerberos
Kerberos é um serviço de autenticação distribuída desenvolvido no MIT (Massachusetts Institute of
Technology) que permite um parceiro provar sua identidade perante um outro parceiro sem enviar
dados confidenciais pela rede. Esse processo é realizado como um serviço de autenticação utilizando
criptografia convencional; opcionalmente ele também fornece integridade e confidencialidade das
mensagens intercambiadas.
2.2.14 Rastreabilidade
É a capacidade de rastrear um elemento do projeto a outros elementos correlatos, especialmente aqueles
relacionados a requisitos.
2.2.15 RMI- Remote Method Invocation
Protocolo de comunicação de objetos remotos Java.
2.2.16 RUP – Rational Unified Process®
O Processo Unificado Rational (também chamado de processo RUP®) é um processo de engenharia de
software que oferece uma abordagem baseada em disciplinas para atribuir tarefas e responsabilidades
dentro de uma organização de desenvolvimento.
2.2.17 Serviço Web (Web Service)
Serviço disponibilizado na web na forma de interfaces de software, permitindo a interoperabilidade de
sistemas.
2.2.18 SOAP – Simple Object Access Protocol
Protocolo simples de acesso a objetos baseado em XML que utiliza para transporte o protocolo HTTP
ou outro, sendo utilizado na comunicação entre Serviços Web.
Computação
Aeronáutica, 2003
181
Glossário
Apêndice 2
Versão:
1.2
Data: 05/10/2003
2.2.19 UDDI- Universal Description, Discover and Integration
Serviço de registro de entidades de negócios e serviços de negócio oferecidos por elas que permite a
descrição, descoberta e integração de Serviços Web.
2.2.20 UML - Unified Modeling Language
É uma linguagem de Modelagem que Visual de sistemas, composta de diversos diagramas que
permitem visões diferenciadas do Projeto de Software, em níveis de abstração diferentes.
2.2.21 X.509 (Certificados Digitais)
Modelo proposto pela ISO que possibilita a implementação de protocolos que autenticam e verificam
chaves públicas em cadeia.
2.2.22 W3C – World Wide Web Consortium
Organização internacional responsável pela padronização de tecnologias para a Web.
2.2.23 WS-I – Web Services Interoperability
Consórcio formado por diversos fabricantes de software que visa acelerar o desenvolvimento e a
implementação dos web services sobre diversas plataformas e aplicações, assim como linguagens de
programação.
2.2.24 WSDL - Web Service Description Language
Linguagem de descrição de Serviços Web utilizada para fornecer detalhes sobre o serviço
disponibilizado, permitindo a implementação de sistemas que interajam com o serviço.
2.2.25 WS-Security
E uma especificação que descreve como conceitos-chave de segurança como encriptação, autenticação,
e assinatura digital, podem ser implementados em Serviços Web.
2.2.26 WS-Transaction
É uma especificação que visa criar mecanismos que permitam a implementação do conceito de
transações em Serviços Web.
Computação
Aeronáutica, 2003
182
ITA – Instituto Tecnológico de Aeronáutica
Plano de Gerenciamento de Requisitos
Versão 1.2
Apêndice 3
WS4PM – Plano de Gerenciamento de Requisitos
Data
Versão
Descrição
Autor
18/02/2003
1.0
Versão Inicial do Documento
Osvandre
21/03/2003
1.1
Celso Hirata
23/07/2003
1.2
Versão Final
Osvandre
184
Apêndice 3
Versão:
1.2
Data: 23/07/2003
Índice Analítico
1.
Introdução
1.1
Finalidade
1.2
Escopo
1.3
Definições, Acrônimos e Abreviações
1.4
Referências
186
186
186
186
186
2.
Gerenciamento de Requisitos
2.1
Organização, Responsabilidades e Interfaces
2.2
Ferramentas, Ambiente e Infra-estrutura
187
187
187
3.
O Programa de Gerenciamento de Requisitos
3.1
Identificação de Requisitos
3.2
Rastreabilidade
3.2.1
Critérios de Solicitações de Envolvidos e Interessados (STRQ)
3.2.2
Critérios de Características (FEAT)
3.2.3
Critérios de Casos de Uso (UC)
3.2.4
Critérios de Especificações Suplementares (SS)
3.3
Atributos
3.3.1
Definição dos Atributos
3.3.1
Utilização dos Atributos por Tipo de Requisito
3.4
Relatórios e Métricas
3.5
Gerenciamento de Mudanças de Requisitos
3.5.1
Processamento e Aprovação de Solicitações de Mudança
3.5.2
Comitê de Controle de Mudança (CCB)
3.5.3
Baselines do Projeto
3.6
Fluxos de Trabalho e Atividades
188
188
189
189
189
189
189
189
189
192
192
192
192
192
192
192
4.
Marcos (milestones)
192
5.
Treinamento e Recursos
192
Computação
Aeronáutica, 2003
185
Apêndice 3
Versão:
1.2
Data: 23/07/2003
1. Introdução
Este documento de Plano de Gerenciamento de Requisitos foi elaborado com base no Modelo de Plano
de Gerenciamento de Requisitos proposto pelo Processo Unificado Rational – PUR (Rational Unified Process RUP) [1] e é parte de um conjunto de artefatos gerados para a documentação do desenvolvimento de Serviços
Web para a Gestão de Projetos (Web Services for Project Management – WS4PM).
1.1
Finalidade
Este documento descreve as regras utilizadas para se estabelecer os documentos de requisitos, tipos,
atributos e a rastreabilidade a serem utilizados para gerenciar os requisitos para a especificação dos Serviços
Web Aplicáveis à Gestão de Projetos, os WS4PM. Ele também serve como documento de configuração para a
ferramenta selecionada para auxiliar o processo de análise e gerenciamento de requisitos.
1.2
Escopo
Este Plano de Gerenciamento de Requisitos documenta a abordagem seguida para registrar, estruturar,
e gerenciar requisitos para a especificação inicial dos WS4PM.
1.3
Vide o documento Glossário.
1.4
Referências
Computação
Aeronáutica, 2003
186
Apêndice 3
Versão:
1.2
Data: 23/07/2003
2. Gerenciamento de Requisitos
Esta seção apresenta a forma como a organização, que está desenvolvendo um projeto de software, está
estruturada em termos de equipe, papéis, responsabilidades e interfaces externas, bem como as ferramentas, o
ambiente e a infra-estrutura desejados para se executar, a contento, o Gerenciamento de Requisitos.
2.1
Organização, Responsabilidades e Interfaces
Segundo o RUP [1], esta seção deve conter informações que definem a Organização que está
desenvolvendo o Projeto de Software, as responsabilidades de cada Papel dentro da Equipe de
Desenvolvimento (Analista, Gerente de Desenvolvimento, Arquiteto de Software, etc) e as Interfaces Externas,
ou seja, pessoas que irão interagir com a equipe de desenvolvimento do projeto durante a especificação e
análise dos requisitos.
Por se tratar de um trabalho acadêmico, desenvolvido por um Aluno sob a orientação de um professor
de uma Instituição de Ensino, esse item será descrito sucintamente conforme a tabela abaixo, no intuito de
fornecer informações sobre os envolvidos nesse trabalho inicial de especificação dos WS4PM.
Organização
IEC – Divisão de Ciência da Computação
Responsabilidades
Especialista em Requisitos
Papel desempenhado pelo aluno que irá capturar a especificação de uma
parte das funcionalidades a serem endereçadas pelos Serviços Web
Aplicáveis à Gestão de Projetos, descrevendo o aspecto Requisitos de
um ou vários casos de uso e outros requisitos de software.
Gerente do Projeto
Papel desempenhado pelo orientador do aluno que irá especificar
prioridades, coordenar as interações com os possíveis usuários dos
serviços que serão especificados, e tentar manter o aluno em sua meta
correta.
Interfaces Externas
O Especialista em Requisitos fará o levantamento de requisitos com
base na pesquisa de campo na Empresa Brasileira de Aeronáutica S/A
(EMBRAER). O principal contato é o Sr. Paulo Cesar Souza Lucas
(Tim), Program Officer EMBRAER-170/190.
2.2
Ferramentas, Ambiente e Infra-estrutura
Para auxiliar o processo de Gerenciamento de Requisitos será necessária a utilização dos seguintes
softwares:
Um editor de textos, por exemplo, o Microsoft Word XP;
Uma ferramenta computacional para apoio à Gerência de Requisitos, por exemplo, o Rational
RequisitePro; e
Um sistema operacional que suporte o uso das ferramentas citadas anteriormente, por
exemplo, o Microsoft Windows 2000.
Os softwares citados anteriormente se encontram disponíveis e instalados nos computadores dos
laboratórios da Divisão de Ciência da Computação do Instituto Tecnológico de Aeronáutica, podendo ser
utilizados para o desenvolvimento dos trabalhos.
Computação
Aeronáutica, 2003
187
Apêndice 3
Versão:
1.2
Data: 23/07/2003
3. O Programa de Gerenciamento de Requisitos
3.1
Identificação de Requisitos
Esta seção descreve os itens de rastreabilidade e define como eles devem ser nomeados, marcados e
numerados.
Para a execução do Gerenciamento de Requisitos referentes aos WS4PM serão considerados e
produzidos os seguintes artefatos :
Título do Documento
Formato do Arquivo
Nome do Arquivo
Documento de Visão
Texto do Microsoft Word
Visão.VIS
Glossário
Glossário.GLS
Considerações e Levantamento
Preliminar de Requisitos de Serviços
Web para a Gestão de Projetos
Considerações e LPR de
Serviços Web para a
Gestão de Projetos.SRS
Especificações Suplementares
Especificações
Suplementares.SS
Com relação a Itens de Rastreabilidade, foram definidos os seguintes :
Identificador
Título
Descrição
STRQ
Solicitação dos Envolvidos
(Stakeholder Requests)
As principais solicitações dos envolvidos e
interessados (stakeholders) WS4PM.
FEAT
Recurso (Feature)
Condições ou recursos endereçados aos
Serviços Web Aplicáveis à Gestão de
Projetos.
UC
Caso de Uso (Use Case – UC)
Requisitos funcionais dos Serviços Web a
serem desenvolvidos. Serão endereçados a
Casos de Uso.
SS
(Supplementary Specifications
- SS)
Requisitos não funcionais para os WS4PM.
A tabela a seguir apresenta os tipos de artefatos ou documentos de requisitos, apontando também, os
Itens de Rastreabilidade contidos neles.
Artefato
Item de Rastreabilidade
(Tipo de Documento)
(Tipo de Requisito)
Visão (VIS)
Solicitação dos Envolvidos (STRQ)
Visão (VIS)
Característica (FEAT)
Considerações e Levantamento Preliminar de
Requisitos de Serviços Web para a Gestão de
Projetos (SRS)
Caso de Uso (UC)
Especificações Suplementares (SS)
Especificação Suplementar (SS)
Computação
Aeronáutica, 2003
188
Apêndice 3
3.2
Versão:
1.2
Data: 23/07/2003
Rastreabilidade
O diagrama a seguir expressa a rastreabilidade entre os ítens identificados anteriormente.
STRQ
FEAT
UC
SS
3.2.1
Critérios de Solicitações de Envolvidos e Interessados (STRQ)
As solicitações dos envolvidos e interessados (STRQ) são descritas em alto nível, e representam, de
forma bastante resumida, o que deve ser endereçado pelos WS4PM a fim de atender as expectativas dos
Envolvidos e Interessados. Elas foram definidas a partir do Documento de Visão e são rastreadas para recursos
oferecidos pelos serviços (FEAT).
3.2.2
Critérios de Características (FEAT)
As características são definidas a partir do detalhamento de itens de Solicitações de Envolvidos e
Interessados (STRQ) e a partir de outros requisitos, alguns deles constantes no documento de Visão. Esses
recursos são rastreados para Casos de Uso (UC) e para Especificações Suplementares (SS). Uma Característica
(FEAT) pode ser rastreado a partir de zero ou mais Casos de Uso (UC), ou a partir de zero ou mais
Especificações Suplementares (SS).
3.2.3
Critérios de Casos de Uso (UC)
São os requisitos de serviços Web para a gestão de projetos que possivelmente serão implementados e
representam algo de valor observável aos usuários. Eles são rastreados para Características (FEAT).
3.2.4
Critérios de Especificações Suplementares (SS)
São os requisitos não funcionais relacionados aos WS4PM que deverão ser observados e atendidos no
ato da implementação. Eles são rastreados para Características (FEAT).
3.3
Atributos
Para cada item de rastreabilidade identificado, são definidos atributos que serão utilizados para
controlar e facilitar a análise dos requisitos de WS4PM.
No Plano de Gerenciamento de Requisitos, os Atributos são primeiramente definidos e na seqüência, é
indicado o seu uso em relação a cada item de rastreabilidade (Tipo de Requisito).
3.3.1
Definição dos Atributos
Atribuído a
Em muitos Projetos, as características serão atribuídas a “Equipes de Recursos” responsáveis por
averiguar e escrever os requisitos do software, e também por sua implementação. Este atributo ajudará
a todos os integrantes da Equipe do Projeto de desenvolvimento dos WS4PM a compreender melhor as
suas responsabilidades.
Afeta a Arquitetura
Computação
Aeronáutica, 2003
189
Apêndice 3
Versão:
1.2
Data: 23/07/2003
O valor desse atributo é booleano (true/false) e é definido pelo Arquiteto de Software. Ele se aplica a
Casos de Uso, possibilitando sua priorização. Casos de Uso arquiteturalmente significativos devem ser
abordados primeiro.
Comentários
Este atributo é um campo do tipo texto designado para inserir comentários a respeito do Requisito. Ele
pode conter, por exemplo, explicações, ou até mesmo exemplificações sobre a solicitação.
Dificuldade
Definido pelo Gerente de Desenvolvimento de uma equipe com base em pesquisas feitas com os
envolvidos e interessados, define a ordem de implementação dos serviços de forma a atender suas
espectativas. Este atributo pode assumir um dos seguintes valores:
Alta
Média
Baixa
Requisito com grau de dificuldade elevado para sua satisfação, o que representa
maior risco para o sucesso do projeto de desenvolvimento dos WS4PM. Devem
ser abordados a priori e satisfeitos ou descartados.
Requisito com grau médio de dificuldade, porém não representa um risco muito
alto para o projeto de desenvolvimento dos WS4PM. Deveria ser abordado logo
após todos os requisitos de dificuldade alta terem sido satisfeitos ou
descartados.
Requisito fácil de se atender, podendo ser satisfeitos a posteriori.
Esforço
Valor a ser definido pela equipe de desenvolvimento, representando as estimativas de tempo e recursos
necessários para o projeto e implementação do requisito. Como algumas funcionalidades necessitam de
mais tempo e de mais recursos do que outras, estimar o número de semanas de participação de cada
pessoa ou equipe, as linhas de código necessárias ou os pontos de função, por exemplo, é uma maneira
de avaliar a complexidade e definir expectativas do que poderá ou não ser feito em um determinado
período de tempo. Podendo ser utilizado no gerenciamento do escopo e na determinação da prioridade
de desenvolvimento.
Estabilidade
Este atributo é definido pelo analista e pela equipe de desenvolvimento. Baseia-se na probabilidade do
requisito sofrer mudanças ou na probabilidade de a equipe vir a compreender o requisito de uma forma
diferente. É usado para ajudar a estabelecer prioridades de desenvolvimento e determinar os itens para
os quais uma averiguação adicional é a próxima ação apropriada.
Prioridade
Definido com base em pesquisas feitas com os envolvidos e interessados, define a ordem de
implementação dos serviços de forma a atender suas expectativas. Este atributo pode assumir um dos
seguintes valores:
Alta
Média
Baixa
Requisitos essenciais. A não-implementação implica que a solução proposta
não atenderá às necessidades do cliente. Todos esses requisitos deverão ser
implementados numa primeira versão do produto.
Requisitos importantes mas num grau de relevância menor que os classificados
com “Prioridade Alta”, sua implementação não necessariamente precisa ser
feita na primeira versão.
Requisitos menos importantes que o cliente gostaria que fossem atendidos,
porém, se o produto não contemplá-los sua satisfação não será afetada.
Release-alvo
Este atributo é um campo do tipo texto utilizado para registrar a versão planejada do produto em que o
Requisito será contemplado. Ele poderá ser usado para alocar Recursos do documento Visão num
190
Computação
Aeronáutica, 2003
Apêndice 3
Versão:
1.2
Data: 23/07/2003
release de baseline específico. Quando este atributo for usado em conjunto com o campo de Status,
descrito a seguir, a Equipe poderá propor, registrar e discutir vários Requisitos do Protótipo do Sistema
sem que eles tenham que ser, necessariamente, desenvolvidos. Somente serão implementados os
Requisitos cujo Status estiverem definidos como Incorporado e cujo Release-Alvo estiver definido.
Quando ocorrer o gerenciamento do escopo, o Número da Versão do Release-alvo poderá ser
aumentado, de modo que o item permaneça no documento Visão, mas seja programado para um release
posterior.
Risco
Definido pela equipe de desenvolvimento e baseado na probabilidade de ocorrerem eventos
indesejáveis no projeto como, por exemplo, custos excessivos, atrasos na programação ou até
cancelamentos. A maior parte dos gerentes de projeto considera que a categorização dos riscos em
altos, médios e baixos é suficiente, embora sejam possíveis gradações ainda mais específicas.
Freqüentemente, os riscos poderão ser avaliados indiretamente medindo-se o grau de incerteza
(intervalo) da programação estimada das equipes dos projetos.
Status
Controla o andamento durante a definição da linha de base da especificação podendo assumir os
seguintes valores:
Proposto
Aprovado
Incorporado
Validado
Usado para descrever Requisitos que estão sendo discutidos, mas que ainda não
foram revisados nem aceitos pelo “canal oficial”.
Requisitos que são considerados úteis e viáveis, e que foram aprovados para
implementação pelo canal oficial.
Requisitos incorporados à baseline do produto, num momento específico no
tempo.
Requisitos que estão incorporados à baseline do produto e que foram validados
pelos usuários e stakeholders.
Classe
Representa se uma determinada Característica especificada afeta a funcionalidade do sistema ou não. É
utilizado para indicar se a Característica representa um Requisito Funcional ou um Requisito Não
Funcional:
Funcional
Não Funcional
Computação
Indica que a característica representa um Requisito Funcional referente aos
WS4PM.
Indica que a característica representa um Requisito Não Funcional referente aos
WS4PM.
Aeronáutica, 2003
191
Apêndice 3
Versão:
1.2
Data: 23/07/2003
3.3.1
Utilização dos Atributos por Tipo de Requisito
A Tabela abaixo exibe o planejamento da utilização do conjunto de atributos definido, para cada Tipo
de Requisito.
Tipo de
Requisito
Atributo
Solicitaçõe
s dos
Envolvidos
(STRQ)
Atribuído a
Afeta a Arquitetura
Comentário
Dificuldade
Esforço
Estabilidade
Prioridade
Release Alvo
Risco
Status
Classe
Recursos
(FEAT)
●
Casos de
Uso (UC)
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
3.4
Relatórios e Métricas
A ser definido.
3.5
Gerenciamento de Mudanças de Requisitos
3.5.1
Processamento e Aprovação de Solicitações de Mudança
A ser definido.
3.5.2
Comitê de Controle de Mudança (CCB)
A ser definido.
3.5.3
Baselines do Projeto
A ser definido.
3.6
Fluxos de Trabalho e Atividades
A ser definido.
Requisitos
Suplementare
s
(SS)
●
●
●
●
●
●
●
●
●
4. Marcos (milestones)
A ser definido.
5. Treinamento e Recursos
A ser definido.
Computação
Aeronáutica, 2003
192
Considerações e Requisitos de Serviços Web
Para
Projetos de Larga Escala
Envolvendo Empresas Parceiras
Apêndice 4
WS4PM – Serviços Web para Gestão de Projetos
Apêndice 4
Versão:
1.0
Data: 15/08/2003
Introdução
Este documento contém um levantamento preliminar de requisitos de
interoperabilidade relacionados aos processos da Gestão de Projetos frente a Projetos de
Larga Escala Envolvendo Parceiros. O PMBOK [PMI00], define esses processos como uma
série de ações que geram resultados e se enquadram em dois grupos: processos da gerência de
projetos e processos orientados a produtos. Com relação aos processos da gerência de projetos
existem trinta e nove processos organizados em cinco grupos e em nove áreas de
conhecimento.
Nas próximas seções desse documento, os grupos de processos e seus
componentes são comentados sucintamente. Uma apresentação das considerações sobre
Projetos de Larga Escala que envolvem parceiros e um levantamento preliminar de requisitos
de interoperabilidade entre esses parceiros são feitos com base numa pesquisa de campo
realizada na Empresa Brasileira de Aeronáutica – EMPBRAER, mais especificamente com a
Gestão do Programa EMBRAER-170/190. As informações coletadas foram confrontadas com
as definições do PMBOK e um conjunto de fichas foi elaborado no sentido de agrupar
informações e facilitar análises. Cada ficha apresenta a seguinte estrutura:
•
um identificador;
•
o nome do processo;
•
a área de conhecimento que o processo se relaciona (entre parênteses);
•
uma breve descrição do processo;
•
uma lista dos processos de seu grupo, sobre os quais sua execução interfere
diretamente; e por fim
•
as eventuais considerações e requisitos identificados.
Às considerações e requisitos são atribuídos identificadores, no intuito de facilitar
análises posteriores. Esses identificadores apresentam uma sintaxe, por exemplo: Ca1.1 é um
identificador que representa uma Consideração apontada no grupo de processos “a”
(Iniciação), processo “1” (Iniciação) cujo contador é 1. Um exemplo de requisito é Rb1.3 que
representa um requisito identificado no grupo de processos “b” (Planejamento), no processo
“1” (Definição das Atividades), cujo contador é 3.
A tabela a seguir, baseada nos processos definidos no PMBOK, além de fornecer
uma visão da abrangência das considerações e requisitos de interoperabilidade especificados,
IEC – Divisão de Ciência
da Computação
Aeronáutica, 2003
194
Apêndice 4
Versão:
1.0
Data: 15/08/2003
exibe a ordem de apresentação e os identificadores atribuídos aos processos, conforme a regra
apresentada no parágrafo anterior.
id
a
a1
b
b1
b2
b3
b4
b5
b6
b7
b8
b9
b10
b11
b12
b13
b14
b15
b16
b17
b18
b19
b20
b21
c
c1
c2
c3
c4
c5
c6
c7
d
d1
d2
d3
d4
d5
d6
d7
d8
e
e1
e2
Processo da Gestão de Projeto
Processo de Iniciação
Planejamento do Escopo
Detalhamento do Escopo
Definição das Atividades
Sequenciamento das Atividades
Estimativa de Duração das Atividades
Desenvolvimento do Cronograma
Planejamento da Gestão de Riscos
Planejamento dos Recursos
Estimativa dos Custos
Orçamentação dos Custos
Desenvolvimento do Plano do Projeto
Planejamento da Qualidade
Planejamento Organizacional
Montagem da Equipe
Planejamento da Comunicação
Identificação dos Riscos
Análise Qualitativa dos Riscos
Análise Quantitativa dos Riscos
Planejamento de Resposta a Riscos
Planejamento de Aquisições
Preparação das Aquisições
Execução do Plano do Projeto
Garantia da Qualidade
Desenvolvimento da Equipe
Distribuição das Informações
Pedido de Propostas
Seleção de Fornecedores
Administração de Contratos
Relato de Desempenho
Controle Integrado de Mudanças
Verificação do Escopo
Controle de Mudanças do Escopo
Controle do Cronograma
Controle dos Custos
Controle da Qualidade
Controle e Monitoração de Riscos
Encerramento de Contratos
Encerramento Administrativo
da Computação
Área de Conhecimento
Gestão do Escopo
Gestão de Escopo
Gestão de Escopo
Gestão de Prazo
Gestão de Prazo
Gestão de Prazo
Gestão de Prazo
Gestão de Riscos
Gestão de Custos
Gestão de Custos
Gestão de Custos
Gestão de RH
Gestão de RH
Gestão de Riscos
Gestão de Riscos
Gestão de Riscos
Gestão de Riscos
Gestão de RH
Gestão de Escopo
Gestão de Escopo
Gestão de Prazo
Gestão de Custos
Gestão de Riscos
Aeronáutica, 2003
195
Apêndice 4
Versão:
1.0
Data: 15/08/2003
Vale salientar que procurou-se fazer considerações e especificar requisitos
relacionados apenas à integração entre os parceiros de projetos, não se preocupando com
detalhes referentes à integração na modalidade EAI, que é feita entre as diversas ferramentas
de apoio à gestão de projetos, como por exemplo, Sistemas de Gestão Empresarial (ERPs),
existentes nas empresas.
da Computação
Aeronáutica, 2003
196
Apêndice 4
Versão:
1.0
Data: 15/08/2003
a) Considerações e Requisitos Relacionados aos
O PMBOK [PMI00], define esse grupo como um conjunto unitário contento
apenas o Processo de Iniciação.
a1) Processo de Iniciação
(Gestão de Escopo )
Visa a obtenção do comprometimento da organização para o início da próxima fase do
projeto.
Processos do grupo sobre os quais interfere diretamente: nenhum
Ca1.1 - Quando os parceiros são fixos, ou já foram definidos previamente, as
informações constantes no Documento de Autorização do Projeto (Project Charter),
emitido com a execução desse processo na Empresa Líder do Projeto, poderiam ser
acessadas pelas Empresas Parceiras do Projeto e Envolvidos (stakeholders);
Ca1.2 – As Empresas Parceiras do Projeto, por sua vez, podem estar retornando sua
manifestação de interesse ou comprometimento em participar do projeto; e
Ca1.3 - Demais informações como restrições e premissas definidas pela Empresa Líder
do Projeto poderiam ser acessadas pelas Empresas Parceiras do Projeto e Envolvidos.
UC1 Ra1.1 – É necessário um serviço que possibilite às Empresas Parceiras do Projeto e
Envolvidos (stakeholders) obterem informações constantes no Documento de
Autorização do Projeto (Project Charter) elaborado pela Empresa Líder do Projeto.
UC2 Ra1.2 – É necessário um serviço que possibilite o registro de manifestação de
interesse ou
comprometimento em participar do projeto por parte das Empresas
Parceiras da Empresa Líder do Projetos; e
UC3 Ra1.3 – É necessário um serviço que permita às Empresas Parceiras do Projeto e
Envolvidos terem acesso a restrições e premissas definidas pela Empresa Líder do
Projeto.
da Computação
Aeronáutica, 2003
197
Apêndice 4
Versão:
1.0
Data: 15/08/2003
b) Considerações e Requisitos Relacionados aos
É o grupo mais numeroso de processos da gestão de projetos. Isso se deve ao fato
do planejamento ser de fundamental importância num projeto. Os processos desse grupo são
subdivididos em dois subgrupos: o de processos essenciais e o de processos facilitadores. A
diferença entre os processos essenciais e os facilitadores é que os essenciais são executados na
mesma ordem, na maioria dos projetos, já os facilitadores são executados intermitentemente e
à medida que são necessários, durante o planejamento do projeto.
Os processos essenciais são onze, e são listados e comentados nas fichas a seguir:
b1) Planejamento do Escopo (Gestão de Escopo )
Visa desenvolver a declaração escrita do escopo, como base para futuras decisões no
projeto. Este processo interage com o processo de declaração do escopo.
Processos do seu grupo sobre os quais interfere diretamente: b2
Cb1.1 – Pode ser necessário compartilhar informações referentes à Declaração do
Escopo, visando entendimento comum entre a Empresa Líder do Projeto e as Empresas
Parceiras do Projeto:
- descrição sumária do produto a ser desenvolvido;
- objetivos macros do projeto; e
- uma lista sumarizada dos subprodutos do projeto identificando aqueles que
cabem à Empresa Parceira que está consultando.
UC4 Rb1.1 – É necessário um serviço que possibilite às Empresas Parceiras do Projeto
obterem a descrição sumária do produto a ser desenvolvido;
UC5 Rb1.2 - É necessário um serviço que possibilite às Empresas Parceiras do Projeto
obterem os objetivos macros do projeto a ser desenvolvido;
UC6 Rb1.3 - É necessário um serviço que possibilite às Empresas Parceiras do Projeto
obterem uma lista sumarizada dos componentes do projeto, identificando aqueles que
lhe cabem.
da Computação
Aeronáutica, 2003
198
Apêndice 4
b2) Detalhamento do Escopo
Versão:
1.0
Data: 15/08/2003
É a subdivisão dos principais subprodutos do projeto em componentes menores e mais
manuseáveis. A execução adequada deste processo é de aspecto crítico para o projeto.
Processos do seu grupo sobre os quais interfere diretamente: b3, b7, b8 e b9.
Cb2.1 - Os subprodutos que são delegados a Empresas Parceiras do Projeto são
detalhados, em alto nível de abstração, pela Empresa Líder do Projeto. No
detalhamento do escopo do projeto eles são citados na WBS e cabe à Empresa
Parceira responsável pela produção do subproduto em questão, criar a WBS referente
ao projeto que ela desenvolverá para concebê-lo.
UC7 Rb2.1 – É necessário um serviço que permita às Empresas Parceiras, acessarem
informações referentes a elementos da WBS do projeto definidos pela Empresa Líder
do Projeto. Elas teriam acesso a informações sobre elementos, que por ventura, lhes
dizem respeito.
b3) Definição das Atividades
(Gestão de Prazo)
Contempla a identificação das atividades específicas que devem ser realizadas para
produzir os diversos subprodutos do projeto.
Processos do seu grupo sobre os quais interfere diretamente: b4 e b5.
Cb3.1 – Os elementos da WBS que são delegados a Empresas Parceiras do Projeto
podem ser definidos como atividades a serem cumpridas cujo recurso alocado às
mesmas são essas empresas. Essas atividades podem ser definidas, em alto nível de
abstração conforme dados da Declaração do Escopo do produto a ser desenvolvido.
As atividades referentes à produção de subprodutos sob responsabilidade das
Empresas Parceiras do Projeto não são especificadas de forma detalhada. Geralmente,
poucas, talvez duas, atividades podem ser definidas no âmbito do projeto de
construção do produto como um todo, seriam por exemplo, Concepção do subproduto
e integração desse subproduto ao produto do projeto.
da Computação
Aeronáutica, 2003
199
Apêndice 4
Versão:
1.0
Data: 15/08/2003
b4) Sequenciamento das Atividades (Gestão de Prazo)
Tem por objetivo identificar e documentar as dependências entre as atividades.
Processos do seu grupo sobre os quais interfere diretamente: b6.
Cb4.1 – Quando um projeto envolve parceiros, pode acontecer deles interferirem no
sequenciamento das atividades devido a particularidades.
UC8 Rb4.1 – É necessário um serviço que permita às Empresas Parceiras registrarem,
junto às Empresas Proprietárias de Projetos, restrições em termos de início e término
de atividades para o desenvolvimento do subproduto que lhe foi delegado.
b5) Estimativa de Duração das Atividades (Gestão de Prazo)
Visa fornecer uma estimativa do esforço, em termos de prazo, que serão necessários
para se completar as atividades individuais.
Cb5.1 – Empresas Parceiras de Projetos podem interagir para auxiliar umas às outras,
conforme as interdependências, para realizar a estimativa de duração das atividades,
por exemplo, a EMBRAER conta com uma Empresa Parceira para o desenvolvimento
da asa de um novo modelo de aeronave. Para efeito de controle do projeto da
aeronave, podem ser definidas apenas duas atividades: a de construção da asa e a de
integração da asa à fuselagem. Nesse caso, a estimativa de duração dessas atividades
depende ou sofre a influência da Empresa Parceira do Projeto.
UC9 Rb5.1 – É necessário um serviço para propiciar às Empresas Parceiras a
capacidade de definirem a duração das atividades que lhes forem delegadas, ou seja, a
Empresa Parceira do Projeto que fabricará a asa de um novo modelo de aeronave,
poderá informar, após a elaboração do projeto desta, o tempo estimado de duração das
atividades de “construção da asa” e “integração da asa à fuselagem”.
da Computação
Aeronáutica, 2003
200
Apêndice 4
b6) Desenvolvimento do Cronograma
Versão:
1.0
Data: 15/08/2003
(Gestão de Prazo)
Visa criar o cronograma do projeto a partir da análise da sequência das atividades,
suas durações, e as necessidades de recursos.
Cb6.1 – Esse processo é executado pela Empresa Líder do Projeto, levando em
consideração as informações definidas para os elementos da WBS que lhe cabem e as
informações obtidas das Empresas Parceiras do Projeto quanto aos elementos da WBS
sob sua responsabilidade. Essas informações são obtidas com a execução dos
processos de definição, sequenciamento e estimativa de duração das atividades, onde,
conforme exposto em Cb4.1 a Empresa Líder do Projeto pode contar com a
colaboração das Empresas Parceiras do Projeto, e elas entre si, para desenvolverem o
cronograma do projeto.
b7) Planejamento da Gestão de Riscos (Gestão de Riscos)
Envolve decidir como abordar e planejar a gestão de risco no projeto.
Cb7.1 – Este processo, em princípio, é executado pelo grupo de projetos da Empresa
Líder e pelo grupo de projeto das Empresas Parceiras do Projeto. Num dado
momento, proprietária e parceiras podem interagir no sentido planejar a gestão de
risco do projeto como um todo, contando com outros envolvidos (stakeholders), por
exemplo: subcontratados e clientes.
UC10 Rb7.1 - É necessário um serviço que permita às Empresas Parceiras do Projeto
e outros stakeholders registrarem junto à Empresa Líder do Projeto informações que
contribuirão para planejamento da gestão de riscos.
da Computação
Aeronáutica, 2003
201
Apêndice 4
b8) Planejamento dos Recursos
Versão:
1.0
Data: 15/08/2003
(Gestão de Custos)
É a determinação de recursos (pessoas equipamentos, materiais, etc.) que devem ser
utilizados, e de suas quantidades, para a realização das atividades do projeto.
Cb8.1 – No caso de projetos que envolvem parceiros, o planejamento dos recursos
necessários ao projeto é feito para os subprodutos que serão desenvolvidos pelo
Project Owner. No caso dos subprodutos que serão delegados a Empresas Parceiras
do Projeto, são identificados os parceiros, e o detalhamento dos recursos é feito por
eles.
Cb8.2 - Caso a Empresa Líder do Projeto tenha feito estimativas de duração das
atividades incluindo um prazo estimado para a concepção de um componente
delegado a uma Empresa Parceira, pode ser
necessário a esta conhecer essa
estimativa.
UC11 Rb8.1 - É necessário um serviço para propiciar às Empresas Parceiras a
capacidade de obter dados do componente que esta deverá desenvolver incluindo a
estimativa de duração apontada pela Empresa Líder do Projeto.
b9) Estimativa dos Custos
(Gestão de Custos)
Visa desenvolver uma estimativa dos custos que são necessários para completar as
atividades do projeto.
Cb9.1 – Este processo antecede a orçamentação de custos, e os valores estimados
aquí são passíveis de alterações. Sendo assim, se as partes julgarem necessário,
podem ser comunicadas as estimativas de custo. Por exemplo, as Empresas Parceiras
podem informar à Empresa Líder do Projeto uma estimativa dos custos para
desenvolvimento de um subproduto para que este possa completar as estimativas de
custos do projeto que ele detém.
UC12 Rb9.1 – É necessário um serviço que possibilite às Empresas Parceiras
comunicarem à Empresa Líder do Projeto as estimativas de custo de seu componente.
UC13 Rb9.2 -
É necessário definir uma unidade monetária comum para os
envolvidos no projeto, que podem estar em partes distintas do mundo, e portanto,
possuem moedas locais diferentes.
da Computação
Aeronáutica, 2003
202
Apêndice 4
Versão:
1.0
Data: 15/08/2003
b10) Orçamentação dos Custos (Gestão de Custos)
É o processo de alocação das estimativas dos custos globais aos pacotes individuais de
trabalho com a finalidade de estabelecer uma linha base de custo para medir o
desempenho do projeto.
Cb10.1 – Em projetos que envolvem parceiros, este processo pode ser executado, em
princípio, isoladamente pela Empresa Líder e pelas Empresas Parceiras do Projeto. Mas
num dado momento há a necessidade de consolidação dos orçamentos para se obter a
orçamentação de custos total do projeto.
comunicarem à Empresa Líder do Projeto as orçamentações de custo de
desenvolvimento do componente que lhe foi delegado.
b11) Desenvolvimento do Plano do Projeto (Gestão da Integração)
É a agregação dos resultados dos outros processos de planejamento construindo um
documento coerente e consistente, utilizado para guiar tanto a execução quanto o
controle do projeto.
Processos do seu grupo sobre os quais interfere diretamente: nenhum.
Cb11.1 - O plano do projeto é um documento aprovado formalmente, usado para
gerenciar e controlar a execução do projeto. Como entrada para esse processo
incluem-se as restrições, premissas e políticas organizacionais. Sendo assim, as
Empresas Parceiras podem contribuir com porções dessas entradas. Por exemplo, uma
Empresa Parceira pode impor uma restrição ou apresentar uma premissa que
influencie o projeto. Além disso, quando o Plano do Projeto já estiver concluído pode
ser interessante às Empresas Parceiras terem acesso a algumas informações contidas
nesse documento e em documentos referentes a detalhes de suporte que também são
concebidos com a execução desse processo.
registrarem restrições, premissas e dados de suas políticas organizacionais que sejam
relevantes para a composição do Plano do Projeto da Empresa Líder do Projeto.
da Computação
Aeronáutica, 2003
203
Apêndice 4
Versão:
1.0
Data: 15/08/2003
UC16 Rb11.2 – É necessário um serviço que permita o acesso, por parte das
Empresas Parceiras, a elementos do Plano do Projeto.
realizarem consultas a porções de informações referentes a detalhes de suporte como
documentação sobre padrões relevantes, documentação técnica, etc.
Os processos facilitadores são dez, e são listados e comentados a seguir:
b12) Planejamento da Qualidade (Gestão da Qualidade)
São ações que visam identificar os padrões de qualidade relevantes para o projeto e
determinar como satisfazê-los.
Cb12.1 – Seria interessante o acesso, por parte das Empresas Parceiras do Projeto,
às políticas de qualidade definidas pela Empresa Líder do Projeto, à declaração do
escopo, à descrição do produto a ser desenvolvido e aos padrões e regulamentos
aplicáveis ao componente que ela desenvolverá.
Cb12.2 - As Empresas Parceiras do Projeto podem comunicar à Empresa Líder do
Projeto os custos relativos ao controle de qualidade para que se consiga obter o custo
de qualidade do projeto como um todo. Os custos de qualidade podem ser de três
tipos: custos de prevenção, custos de avaliação e custos de falha, onde este último
pode ser dividido em interno e externo.
consultarem políticas de qualidade definidas pela Empresa Líder do Projeto.
obterem a definição do produto feita pela Empresa Líder do Projeto.
obterem a definição do escopo do produto feita pela Empresa Líder do Projeto.
obterem os padrões e regulamentos definidos pela Empresa Proprietário do Projeto.
informarem à Empresa Líder do Projeto, os custos relativos ao controle de qualidade
de seu componente para que essa possa obter o custo total da qualidade do projeto.
da Computação
Aeronáutica, 2003
204
Apêndice 4
Versão:
1.0
Data: 15/08/2003
b13) Planejamento Organizacional (Gestão de RH)
É a identificação, documentação e atribuição de papéis, responsabilidades e relações
hierárquicas no projeto.
Cb13.1 – O planejamento organizacional é um processo interno às organizações e
portanto, não foram identificados requisitos de integração e comunicação entre as
Empresas Parceiras e a Proprietária do Projeto. Contudo, fica uma dúvida quanto a
relação de hierarquia entre Proprietárias do Projeto e Parceiras do Projeto,
principalmente quando se trata dos times integrados (joint teams).
b14) Montagem da Equipe (Gestão de RH)
Visa conseguir que os recursos humanos necessários sejam designados e alocados ao
projeto.
Cb14.1 – A montagem da equipe, no tocante ao contexto de parcerias em projetos,
pode envolver a seleção desses parceiros, caso haja mais de um que possa ser
destinado a um dado componente.
b15) Planejamento da Comunicação (Gestão da Comunicação)
Visa determinar as necessidades das partes envolvidas quanto à informação e
comunicação, ou seja, quem necessita de qual informação, quando e como a
informação será fornecida.
Cb15.1 – As Empresas Parceiras do Projeto podem comunicar à Proprietária do
Projeto seus requisitos de comunicação, e vice-versa.
Os Requisitos de
comunicações, as tecnologias de comunicações, as restrições e premissas são obtidas
dos envolvidos no projeto para compor o plano de comunicação.
Cb15.2 – A elaboração de um portal, a utilização de mecanismos de mensagem
síncronos e assíncronos, podem ser uma boa alternativa, e que inclusive, já vem sido
da Computação
Aeronáutica, 2003
205
Apêndice 4
Versão:
1.0
Data: 15/08/2003
utilizado pela EMBRAER.
UC23 Rb15.1 – É necessário um serviço que possibilite à Proprietária do Projeto e às
Empresas Parceiras registrarem seus requisitos de comunicação, ou seja, que
informações eles esperam um do outro.
SS20 Rb15.2 – É necessário definir um Portal de Comunicação que permita a
interação entre a Proprietária e as Parceiras do Projeto onde alguns serviços propostos
nesse documento pudessem ser acessados, estendendo a implementação de eventuais
portais atualmente utilizados por Empresas Proprietárias de Projeto.
b16) Identificação dos Riscos
(Gestão de Riscos)
Visa a determinação dos riscos prováveis do projeto e a documentação das
características de cada um.
Cb16.1 – Cada Empresa Parceira do Projeto e a Proprietária executam o processo de
identificação de riscos para os produtos que lhes competem. Os riscos identificados
em componentes delegados a Empresas Parceiras, que por ventura representem um
risco potencial para o projeto como um todo, podem ser levados ao conhecimento da
Proprietária do Projeto que passará a encarar esse risco como um risco para o projeto.
UC24 Rb16.1 – É necessário um serviço que permita às Empresas Parceiras
registrarem riscos relacionados a seu subproduto que podem comprometer o
desempenho do projeto como um todo, levando tal informação a conhecimento da
UC25 Rb16.2 - Podem ser definidos gatilhos que podem ser disparados caso marcos
intermediários definidos não sejam atingidos, advertindo a equipe do projeto de um
atraso eminente no projeto. Alguns marcos intermediários podem ser definidos nas
Empresas Parceiras e gatilhos podem ser associados a eles de forma que advertências
lhes são reportadas e até reportadas à Proprietária do Projeto automaticamente.
da Computação
Aeronáutica, 2003
206
Apêndice 4
Versão:
1.0
Data: 15/08/2003
b17) Análise Qualitativa dos Riscos (Gestão de Riscos)
Visa analisar qualitativamente os riscos e condições para priorizar seus efeitos nos
objetivos do projeto.
Cb17.1 - Este processo é executado isoladamente pela Proprietária do Projeto e pelas
Parceiras do Projeto com relação aos riscos específicos de seus produtos e
componentes.
Porém os resultados dessas análise podem ser comunicados das
Parceiras do Projeto para a Proprietária.
UC26 Rb17.1 – É necessário um serviço que permita o acesso dos envolvidos num
projeto a informações referentes à classificação dos riscos globais para o projeto. No
caso de componentes delegados a Empresas Parceiras do Projeto pode-se ter acesso à
classificação de risco global para o projeto dos componentes sob sua
responsabilidade;
UC27 Rb17.2 – É necessário um serviço que possibilite o acesso, por parte da
Empresa Propritária do Projeto, à lista de riscos prioritários das Empresas Parceiras
do Projeto;
UC28 Rb17.3 – É necessário um serviço que permita o acesso, por parte da Empresa
Líder do Projeto, a informações referentes a itens da Lista de Riscos das Empresas
Parceiras para análise e gerenciamento adicionais; e
UC29 Rb17.4 - É necessário um serviço que permita à Empresa Líder do Projeto
obter informações a respeito da tendência em resultados da Análise Qualitativa de
Riscos dos componentes delegados a Empresas Parceiras do Projeto.
b18) Análise Quantitativa dos Riscos (Gestão de Riscos)
Resume em mensurar a probabilidade e o impacto dos riscos e estimar suas
implicações nos objetivos do projeto.
Cb18.1 - Este processo é executado isoladamente pela Empresa Líder do Projeto e
pelas Parcerias do Projeto, com relação aos riscos específicos de seus produtos e
componentes.
Porém os resultados dessas análise podem ser comunicados das
Parceiras para a Proprietária.
UC30 Rb18.1 – É necessário um serviço que permita à Empresa Líder do Projeto
da Computação
Aeronáutica, 2003
207
Apêndice 4
Versão:
1.0
Data: 15/08/2003
obter a lista priorizada dos riscos quantificados dos projetos de componentes
delegados a Empresas Parceiras;
UC31 Rb18.2 – É necessário um serviço que permita à Proprietária do Projeto obter
resultados da Análise Probabilística dos projetos de componentes delegados a
Empresas Parceiras;
obter a probabilidade de se alcançar os objetivos de custo e de tempo dos projetos de
componentes sob a responsabilidade de Empresas Parceiras do Projeto; e
obter as tendências no resultado da análise quantitativa dos riscos dos projetos de
componentes sob responsabilidade de Empresas Parceiras.
b19) Planejamento de Resposta a Riscos (Gestão de Riscos)
Visa desenvolver procedimentos e técnicas para aumentar as oportunidades e para
reduzir ameaças de riscos para os objetivos do projeto.
Processos do seu grupo sobre os quais interfere diretamente:nenhum.
Cb19.1 - Este processo é executado isoladamente pela Empresa Líder do Projeto e
pelas Empresas Parceiras do Projeto com relação aos riscos específicos de seus
produtos e componentes. Quando o risco é considerado potencial para o projeto, a
Empresa Líder e a Parceria podem planejar uma resposta juntas.
UC34 Rb19.1 – É necessário um serviço que permita às Empresas Parceiras do
Projeto registrarem, junto à Empresa Líder do Projeto, informações sobre riscos do
projeto que estão desenvolvendo e que são considerados riscos potenciais para o
Projeto de Larga Escala como um todo , permitindo o planejamento em conjunto de
resposta a esses riscos.
da Computação
Aeronáutica, 2003
208
Apêndice 4
Versão:
1.0
Data: 15/08/2003
b20) Planejamento de Aquisições (Gestão de Aquisição)
É a determinação de “o que” contratar e “quando” contratar.
Processos do seu grupo sobre os quais interfere diretamente:b10.
Cb20.1 – Geralmente esse processo é interno a cada parceiro, mas pode ser necessário
à Empresa Líder do Projeto saber se as empresas Parceiras possuem “saúde
financeira” para cumprir os contratos de aquisição, uma vez que a ausência de fundos
num parceiro representa um risco para o projeto.
UC35 Rb20.1 – É necessário um serviço que permita aos parceiros de projetos
(Empresa Líder do Projeto e Empresa Parceira do Projeto) conhecerem, mutuamente,
sua “saúde financeira”.
b21) Preparação das Aquisições (Gestão de Aquisição)
Visa documentar os requisitos do produto/serviço a ser adquirido e as fontes possíveis
de fornecimento.
Processos do seu grupo sobre os quais interfere diretamente:nenhum.
Cb21.1 – Interno a cada parceiro (Verificar Integração EAI) .
da Computação
Aeronáutica, 2003
209
Apêndice 4
Versão:
1.0
Data: 15/08/2003
c) Considerações e Requisitos Relacionados aos
Este grupo de processos também inclui processos essenciais e facilitadores.
Como processo essencial consta apenas um:
C1) Execução do Plano do Projeto (Gestão da Integração)
Visa a concretização do plano do projeto através da realização das atividades nele
incluídas.
Cc1.1 – Registros sobre resultados do trabalho e requisições de mudanças são
esperados como saída desse processo. No tocante a parceiros de projetos seria
interessante a disseminação, a
quem de direito, de informações referentes aos
resultados e requisições de mudanças, agilizando o processo de tomada de decisão e
replanejamento.
UC36 Rc1.1 – É necessário um serviço que permita o registro e consulta a resultados
do trabalho executado tanto na Empresa Líder do Projeto quanto nas Empresas
Parceiras do Projeto, oferecendo visibilidade a quem de direito.
UC37 Rc1.2 – É necessário um serviço que permita tanto à Empresa Líder do Projeto
quanto às Empresas Parceiras registrarem e comunicarem solicitações de mudanças,
disparando gatilhos de comunicação para os envolvidos.
Como processos facilitadores cita-se seis. São eles:
C2) Garantia da Qualidade
(Gestão da Qualidade)
É avaliar regularmente o desempenho geral do projeto com o objetivo de prover
confiança de que o projeto irá satisfazer os padrões estabelecidos de qualidade.
Cc2.1 – Resultados de medição do controle da qualidade dos subprodutos
desenvolvidos pelas Empresas Parceiras do Projeto
podem ser transmitidas
à
Empresa Líder do Projeto para que esta possa fazer a medição da qualidade do
produto que está sendo desenvolvido.
da Computação
Aeronáutica, 2003
210
Apêndice 4
Versão:
1.0
Data: 15/08/2003
UC38 Rc2.1 – É necessário um serviço que possibilite às Empresas Parceiras do
Projeto relatarem de forma automatizada os resultados de medição do controle de
qualidade do componente que ela está desenvolvendo.
c3) Desenvolvimento da Equipe (Gestão de RH)
Visa desenvolver habilidades das pessoas e da equipe, enquanto grupo, para melhorar
o desempenho do projeto.
Cc3.1 – O desenvolvimento da equipe, tanto em Empresas Parceiras quanto em
Empresas Proprietárias do Projeto, é um processo interno da organização, em relação
ao produto que será desenvolvido.
c4) Distribuição das Informações (Gestão da Comunicação)
É a disponibilização das informações necessárias, e no momento adequado, às partes
envolvidas.
Cc4.1 – O objetivo principal desse processo é disponibilizar, de forma regular, as
informações necessárias às partes envolvidas no projeto. Nesse caso a distribuição de
informações poderia ser feita da forma mais automatizada possível, à medida que
eventos forem disparados. O serviços especificados neste documento visam auxiliar
esse processo diretamente.
c5) Pedido de Propostas
(Gestão de Aquisição)
Obter, conforme apropriado a cada caso (cotações de preço, cartas-convite, licitações,
concorrências), as propostas de fornecimento dos produtos e ou serviços pretendidos.
Processos do seu grupo sobre os quais interfere diretamente: c6.
Cc5.1 – Este processo é interno a cada parceiro (Verificar Integração EAI)
da Computação
Aeronáutica, 2003
211
Apêndice 4
Versão:
1.0
Data: 15/08/2003
c6) Seleção de Fornecedores (Gestão de Aquisição)
É o ato de escolher entre os possíveis fornecedores, aqueles que serão contratados
para o projeto.
Processos do seu grupo sobre os quais interfere diretamente: c7.
c7) Administração de Contratos (Gestão de Aquisição)
É o conjunto de ações que visam gerenciar os relacionamentos com os fornecedores.
da Computação
Aeronáutica, 2003
212
Apêndice 4
Versão:
1.0
Data: 15/08/2003
d) Considerações e Requisitos Relacionados aos
Esses processos são ações que visam monitorar e medir o desempenho do projeto
regularmente, no sentido de se analisar os desvios para se detectar possíveis riscos para o
projeto. A identificação de desvios significativos pode exigir reajustes no plano do projeto.
Controlar também inclui tomar ações corretivas, antecipando-se aos problemas. Neste grupo
de processos também existem processos essenciais e facilitadores.
Como processos essenciais pode-se citar dois:
d1) Relato de Desempenho (Gestão da Comunicação)
É a coleta e divulgação de informações de desempenho do projeto incluindo relatórios
de status, medidas de progresso, e novas estimativas do projeto.
Cd1.1 – Relatórios de situação (posição com relação ao cronograma e ao orçamento),
progresso (percentual de atividades realizadas, em andamento versus completadas) e
previsões (predizem o futuro do projeto em termos de situação e andamento) podem
ser enviadas de forma automática.
Cd1.2 – O valor das variáveis utilizadas nas análises de variação, tendências e valor
obtido podem ser encaminhados das Empresas Parceiras do Projeto para a Empresa
Líder do Projeto para que esta consolide as informações e consiga ter a análise do
UC39 Rd1.1 – É necessário um serviço que permita à Empresa Líder do Projeto obter
dados de relatórios de situação, progresso e previsões gerados pelas Empresas
Parceiras do Projeto.
UC40 Rd1.2 – É necessário um serviço que automaticamente, ou não, envie dados
referentes a análises de tendência, variação e valor obtido das Empresas Parceiras
para a Empresa Líder do Projeto.
UC41 Rd1.3 – É necessário um serviço que permita o registro de requisições de
mudanças, vindas tanto da Proprietária do Projeto quanto da Parceiras, mediante a
análise de desempenho do projeto.
da Computação
Aeronáutica, 2003
213
Apêndice 4
Versão:
1.0
Data: 15/08/2003
d2) Controle Integrado de Mudanças (Gestão da Integração)
São ações de coordenação de mudanças através de todo o projeto. Esse controle
requer: manter a integridade das medidas básicas de desempenho, assegurar que as
mudanças no escopo do produto sejam refletidas na definição do escopo do projeto e
coordenar as mudanças entre as áreas de conhecimento da gestão de projetos pois uma
mudança no escopo do produto frequentemente afetará os custos, o risco a qualidade,
etc.
Cd2.1 – Para facilitar a execução desse processo, as Empresas Parceiras do Projeto
podem interferir oferecendo relatos de desempenho e requisições de mudanças. Isso já
está discutido na execução do plano do projeto (c.1). Esse processo refere-se a um
conjunto de ações que são executadas de forma isolada pela Empresa Líder do
Projeto. Sendo assim, a influência externa à organização, nesse processo, está no fato
de que a Empresa Líder e as Parceiras podem gerar entradas para ele.
UC42 Rd2.1 – É necessário um serviço que possibilite atualizações no Plano do
Projeto, tanto por parte da Empresa Líder quanto por parte das Empresas Parceiras,
porém, de forma coordenada.
O processos facilitadores desse grupo são seis:
d3) Verificação do Escopo
É a aceitação formal do escopo e dos resultados do projeto pelas partes envolvidas.
Cd3.1 – No caso de projetos que envolvem parceiros a comunicação do escopo aos
envolvidos no projeto pode ser interessante, bem como uma forma de se ter a
aceitação por parte de todos os envolvidos.
UC43 Rd3.1 - É necessário um serviço que possibilite o registro de aceitação do
escopo do Projeto de Larga Escala, por parte das Empresas Parceiras, mediante
informação de senha pertencente apenas aos coordenadores de projetos das Parceiras
envolvidas.
Com isso, poderia-se ter o acompanhamento da aceitação comum da
WBS do projeto, permitindo inclusive a identificação dos componentes cujas
parceiras contatadas ainda não registraram sua aceitação.
da Computação
Aeronáutica, 2003
214
Apêndice 4
Versão:
1.0
Data: 15/08/2003
d4) Controle de Mudanças do Escopo (Gestão de Escopo )
É o controle efetivo de mudanças no escopo do projeto
Cd4.1 - Em projetos de larga escala, uma solicitação de mudança no escopo de um
componente pode afetar o escopo de parte ou todo o projeto. Podem ser necessários
mecanismos que auxiliem no registro e comunicação de mudanças no escopo.
UC44 Rd4.1 – É necessário um serviço que permita às Empresas Parceiras
registrarem informações que comporão relatórios de desempenho;
UC45 Rd4.2 – É necessário um serviço que possibilite à Empresa Líder do Projeto
registrar requisições de mudanças no escopo. Mediante o registro de requisições de
mudanças, gatilhos podem ser disparados informando determinadas pessoas;
UC46 Rd4.3 – É necessário um serviço que possibilite a comunicação às Empresas
Parceiras do Projeto, sobre mudanças sugeridas, em aprovação e aprovadas em
relação ao escopo do projeto.
d5) Controle do Cronograma
(Gestão de Prazo )
É o controle efetivo de mudanças no cronograma do projeto.
Cd5.1 – O controle do cronograma consiste em influenciar os fatores que criam
mudanças no cronograma para garantir que as mudanças sejam benéficas, determinar
que o cronograma foi alterado e gerenciar mudanças reais, quando e como elas
ocorrem. No caso de projetos que envolvem parceiros relatos de desempenho das
Empresas Parceiras do Projeto podem ser acessados pela Empresa Líder do Projeto
para que o mesmo consiga medir o desempenho do projeto como um todo.
UC47 Rd5.1 – É necessário um serviço que possibilite à Empresa Líder do Projeto
tomar conhecimento de atualizações no cronograma, feitas pelas Empresas Parceiras
do Projeto.
UC48 Rd5.2 – É necessário um serviço que possibilite às Empresas Parceiras
tomarem conhecimento de atualizações feitas no cronograma, pela Empresa Líder do
Projeto.
da Computação
Aeronáutica, 2003
215
Apêndice 4
Versão:
1.0
Data: 15/08/2003
d6) Controle dos Custos (Gestão de Custos)
É o controle efetivo de mudanças no orçamento do projeto em relação à linha base de
custos estabelecida na orçamentação dos custos.
Cd6.1 – Como entradas para esse processo, são listadas: a linha base de custos,
relatórios de desempenho, requisições de mudança e o plano de gerenciamento de
custos. Desse conjunto, os itens que sofrem uma influência maior das Empresas
Parceiras do Projeto são os relatórios de desempenho, as requisições de mudança e a
linha base de custo dos componentes.
Cd6.2 – Uma das ferramentas utilizadas para auxiliar esse processo é o
Gerenciamento de Valor Obtido. No caso dos componentes delegados a Empresas
Parceiras, esse gerenciamento é feito por elas, que podem estar informando os valores
das variáveis dessa ferramenta que incidirão na análise feita pela Empresa Líder do
Projeto.
informarem à Empresa Líder do Projeto valores referentes aos totais das variáveis da
Análise de Valor Obtido dos projetos dos componentes que elas estão desenvolvendo,
para que a Proprietária possa acompanhar o desempenho do projeto como um todo.
UC50 Rd6.2 – É necessário um serviço que possibilite às Empresas Parceiras do
Projeto obterem informações sobre a Análise de Valor Obtido do Projeto de Larga
Escala como um todo.
d7) Controle da Qualidade
(Gestão da Qualidade)
É o ato de monitorar resultados específicos do projeto para determinar se eles atingem
padrões de adequados de qualidade, e identificar ações para eliminar as causas de
desempenhos insatisfatório.
Cd7.1 – As Empresas Parceiras do Projeto podem ter acesso aos padrões de qualidade
especificados pela Empresa Líder do Projeto, para o projeto como um todo. Com isso,
as Empresas Parceiras do Projeto podem monitorar seus resultados, verificando se
estão de acordo com os padrões estabelecidos para o produto como um todo.
da Computação
Aeronáutica, 2003
216
Apêndice 4
Versão:
1.0
Data: 15/08/2003
obterem informações referentes aos Padrões de Qualidade estabelecidos pela Empresa
Líder do Projeto, para o produto como um todo.
d8) Controle e Monitoração de Riscos (Gestão de Riscos)
Acompanhar os riscos identificados, monitorar os riscos residuais e identificar nos
riscos, garantindo a execução dos planos de risco e avaliar sua efetividade em reduzir
riscos.
Cd8.1 - Este processo é executado pela Empresa Líder do Projeto e pelas Empresas
Parceiras do Projeto com relação aos riscos específicos de seus produtos e
componentes. Porém, algumas informações podem ser reportadas à Empresa Líder do
Projeto.
UC52 Rd8.1 – É necessário um serviço que informe à Empresa Líder do Projeto,
valores referentes a variáveis de controle e monitoramento de riscos referentes à
execução dos projetos de componentes delegados a empresas parceiras .
da Computação
Aeronáutica, 2003
217
Apêndice 4
Versão:
1.0
Data: 15/08/2003
e) Considerações e Requisitos Relacionados aos
Este grupo é composto de dois processos essenciais que são:
e1) Encerramento de Contratos (Gestão de Aquisição)
É o ato de completar e liquidar o contrato, incluindo a resolução de qualquer item
pendente.
Processos do seu grupo sobre os quais interfere diretamente: e2.
Ce1.1 – Ao se encerrar um contrato entre uma Empresa Parceira e a Proprietária do
Projeto, toda e qualquer comunicação de informação referente ao projeto do
componente produzido deveria ser inibida, de forma que não se pudesse mais alterar
informações referentes ao controle do projeto desse componente.
UC53 Re1.1 – É necessário um serviço que registre o encerramento do contrato entre
a Empresa Líder e a Parceira para um determinado componente do projeto. Dessa
forma, a Empresa Líder passa a não receber mais informações referentes ao elemento
da WBS de seu projeto que se relaciona ao projeto do componente desenvolvido pela
Empresa Parceira.
e2) Encerramento Administrativo (Gestão da Comunicação)
Visa gerar, reunir e disseminar informações para formalizar o término da fase ou
projeto, incluindo avaliações do projeto e compilação das lições aprendidas para uso
em planejamentos de futuros projetos ou fases.
Ce2.1 – O projeto ou fase, depois de alcançar seus objetivos ou terminado por outras
razões necessita ser encerrado. No caso das Empresas Parceiras do Projeto, pode ser
feito o encerramento administrativo do projeto e para a Empresa Líder do Projeto
esse encerramento refletirá como o encerramento de uma atividade, a concepção do
componente em questão.
da Computação
Aeronáutica, 2003
218
Apêndice 4
Versão:
1.0
Data: 15/08/2003
UC54 Re2.1 – É necessário um serviço que permita marcar o percentual de
completude de um determinado elemento na WBS do Projeto, na Empresa
Proprietária, mediante o registro do encerramento administrativo, por parte das
Empresas Parceiras, para o término de uma fase ou conclusão de um componente que
lhe foi delegado.
Segundo o PMBOK [PMI00], as interações entre os processos dos grupos apresentados
anteriormente são aplicáveis à maioria dos projetos durante a maior parte do tempo.
Entretanto, nem todos os processos são necessários, e nem todas as interações se aplicam. No
caso da EMBRAER, que é uma organização que faz amplo uso de parcerias e
subcontratações, ela pode explicitar exatamente onde, no processo de planejamento, cada
contratação deve ocorrer. Grandes projetos, como os executados por ela, podem necessitar de
maiores detalhes. Por exemplo, a identificação de riscos pode ser subdividida para focalizar
separadamente os riscos de custo, os riscos de prazos, os riscos técnicos e os riscos de
qualidade. Em subprojetos e projetos menores, gasta-se um pequeno esforço nos processos
cujas saídas já tenham sido definidas ao nível do projeto, ou seja, a empresa contratante olha
para o subproduto delegado a um terceiro de forma mais macro.
Conclusão
Este documento procurou sugerir, com base nos processos definidos pelo PMI e
levando em consideração, características de projetos de larga escala que envolvem parceiros,
um conjunto de requisitos de serviços, que podem ser implementados em Softwares de Gestão
de Projetos, a fim de se prover a interoperabilidade entre parceiros de projetos.
É comum em projetos de larga escala que envolvem parceiros, o estabelecimento
de escritórios devidamente equipados, tanto em termos de recursos humanos, quanto de
recursos tecnológicos, destinados à sua gestão e integração com as unidades funcionais da
organização, onde o volume de utilização de softwares que poderiam invocar esses serviços é
consideravelmente grande.
da Computação
Aeronáutica, 2003
219
Apêndice 4
Versão:
1.0
Data: 15/08/2003
Os serviços propostos aqui, podem vir a ser implementados em Softwares de
Gestão de Projetos, através do uso de tecnologias específicas, como a de Web Services, por
exemplo.
Não se teve a intensão de ser completo nas especificações feitas aquí, uma vez que
cada uma delas encontra-se definida num nível de abstração um pouco alto. Vale salientar que
a finalidade desse documento foi a de propor um conjunto de serviços, onde cada um deles
deverá ser validado, e numa próxima fase, aqueles que foram aprovados deverão ser
detalhados, e implementados.
Referências Bibliográficas
[PMI00] PMI – Project Management Institute. PMBOK 2000 - A Guide to the Project
Management Body of Knowledge – PMBOK Guide, 2000.
da Computação
Aeronáutica, 2003
220
Versão 1.1
Apêndice 5
Data
Versão
Descrição
Autor
30/06/03
1.0
Versão Inicial
Osvandre
10/09/03
1.1
Versão Final – Conforme Revisão do
Orientador
Osvandre / Celso Hirata
222
Apêndice 5
Versão:
1.0
Data: 10/09/03
Índice Analítico
1.
Introdução
1.1
Finalidade
1.2
Escopo
1.3
1.4
Referências
2.
Requisitos de Funcionalidade
224
2.1
2.2
224
224
Log de Erros
Parametrização de informações de acesso aos WS4PM
224
224
224
224
224
3.
Requisitos de Usabilidade
3.1
Registro do Negócio e Serviços em Servidores de Serviços UDDI
3.2
Descrição de Web Services em WSDL
3.3
Conexão a uma rede (Internet ou Intranet)
3.4
Interação mínina dos usuários
3.5
Transposição de Firewalls
224
225
225
225
225
225
4.
Requisitos de Confiabilidade
4.1
Disponibilidade 24x7
4.2
Controle de Transações
225
225
225
5.
Requisitos de Desempenho
5.1
Tempo de Resposta
5.2
Acessos Simultâneos
225
225
225
6.
Requisitos de Suportabilidade
225
7.
Requisitos de Restrições de Projeto (Design)
7.1
Independência de interface na porção Consumidora
7.2
Independência da plataforma de desenvolvimento da aplicação consumidora
7.3
Utilização da XML
7.4
Arquitetura em Camadas
226
226
226
226
226
8.
Requisitos de Segurança
8.1
Políticas de Autorização
8.2
Autenticação e Segurança Digital
226
226
226
9.
Requisitos de Padrões Aplicáveis
9.1
Padrões propostos pela W3C (World Wide Web Consortium).
9.2
Padrões propostos pela WS-I (Web Services Interoperability).
226
226
226
Aeronáutica, 2003
223
Computação
Apêndice 5
Versão:
1.0
Data: 10/09/03
1. Introdução
Este documento de Especificações Suplementares foi elaborado com base no Modelo de documento de
Especificações Suplementares proposto pelo Processo Unificado Rational – PUR (Rational Unified Process - RUP)
[1] e é parte de um conjunto de artefatos gerados para a documentação do desenvolvimento de Web Services
Aplicáveis à Gestão de Projetos (Web Services for Project Management – WS4PM).
1.1
Finalidade
A finalidade deste documento é definir os Requisitos Não Funcionais para os Serviços Web Aplicáveis à
Gestão de Projetos (Web Services for Project Management – WS4PM). As Especificações Suplementares e o
Modelo de Casos de Uso, juntos, originaram o conjunto completo de requisitos dos WS4PM.
1.2
Escopo
Este documento de Especificações Suplementares aplica-se aos WS4PM e define requisitos não-funcionais
como: requisitos de usabilidade, confiabilidade, desempenho e suportabilidade, bem como alguns requisitos de
funcionalidade, comuns a vários Casos de Uso, que foram identificados inicialmente. Os itens listados neste
documento ilustram alguns Requisitos Não Funcionais geralmente aplicáveis a Serviços Web. Valores, como os
apresentados nos requisitos de desempenho, representam estimativas que necessitam de validações.
Os parágrafos que possuem os identificadores SS seguidos de um número indicam que estes foram
rastreados para a ferramenta utilizada para auxiliar o processo de análise e gerenciamento de requisitos
RequisitePro.
1.3
Vide documento Glossário.
1.4
Referências
[1] RUP – Rational Unified Process v2002.05.00, Copyright © Rational Software Corporation
[2] W3C – World Wide Web Consortium : Web Services Activity : Acessível a partir de www.w3c.org :
[3] WS-I – Web Services Interoperability : Acessível a partir de www.ws-i.org
2. Requisitos de Funcionalidade
Esta seção lista requisitos funcionais que são comuns a mais de um caso de uso.
2.1
Log de Erros
SS1 Quando ocorrerem falhas em transações e processamentos devem ser registrados logs de erros tanto
nos provedores quanto nos consumidores de WS4PM.
2.2
Parametrização de informações de acesso aos WS4PM
SS2 Na implementação de aplicações consumidoras dos WS4PM deve-se propiciar aos usuários a
possibilidade de parametrizarem informações que customizem endereços de acesso, nomes dos serviços e
outros dados sensíveis à escolha de parceiros de projetos.
3. Requisitos de Usabilidade
Nesta seção são descritos os requisitos que afetam a usabilidade dos WS4PM.
Computação
Aeronáutica, 2003
224
Apêndice 5
Versão:
1.0
Data: 10/09/03
3.1
Registro do Negócio e Serviços em Servidores de Serviços UDDI
SS3 Os usuários de WS4PM devem registrar informações sobre o seu negócio e os WS4PM disponíveis,
facilitando a integração com parceiros.
3.2
Descrição de Web Services em WSDL
SS4 Uma descrição do Serviço Web implementado deve ser provida em documentos WSDL, propiciando
facilidades na implementação de consumidores.
3.3
Conexão a uma rede (Internet ou Intranet)
SS5 É indispensável que as estações que acessarão os WS4PM estejam conectadas à rede mundial de
computadores (Internet) ou a uma rede privada, a uma velocidade média de 128Kbps .
3.4
Interação mínina dos usuários
SS6 Quando da implementação dos WS4PM em Softwares de Gestão de Projetos, deve-se primar para que
a aplicação comsumidora exija o mínimo de interação dos usuários, utilizando-se recursos como gatilhos
em eventos disparados quando da utilização das funcionalidades desses softwares.
3.5
Transposição de Firewalls
SS7 Os sistemas de proteção contra invasões do tipo firewalls não devem impedir que consumidores
acessem as funcionalidades expostas pelos WS4PM.
4. Requisitos de Confiabilidade
Nesta seção são especificados requisitos de confiabilidade do sistema, envolvendo itens como disponibilidade,
tolerância a falhas, etc.
4.1
Disponibilidade 24x7
SS8 Os Serviços Web Aplicáveis à Gestão de Projetos devem estar disponíveis para consumo 24 horas por
dia e 7 dias por semana (24x7).
4.2
Controle de Transações
SS9 Devem ser implementados mecanismos para o controle de transações que envolvem parceiros,
incluindo a capacidade de se desfazer uma transação incompleta (Rollback).
5. Requisitos de Desempenho
As características de desempenho dos WS4PM são descritas nesta seção, incluindo tempos de resposta
específicos.
5.1
Tempo de Resposta
SS10 Deve-se primar para que cada transação, exceto aquelas que envolvam o tráfego de elementos
atachados, como desenhos por exemplo, durem no máximo 10 segundos.
5.2
Acessos Simultâneos
SS11 Os WS4PM devem ser escaláveis, suportando acessos “simultâneos” de consumidores, na faixa de 1
a 3000.
6. Requisitos de Suportabilidade
Esta seção indica todos os requisitos que aprimorarão a suportabilidade ou manutenibilidade dos WS4PM,
incluindo padrões de codificação, convenções de nomeação, bibliotecas de classes, dentre outros.
Computação
Aeronáutica, 2003
225
Apêndice 5
Versão:
1.0
Data: 10/09/03
A ser definido.
7. Requisitos de Restrições de Projeto (Design)
Este conjunto de requisitos especifica um conjunto de itens arquiteturalmente significativos para se garantir a
interoperabilidade.
7.1
Independência de interface na porção Consumidora
SS12 Os WS4PM devem ser desenvolvidos de forma a não impor restrições à implementação de interfaces
de usuário no desenvolvimento de aplicações consumidoras, ou seja, qualquer tipo de implementação, seja
ela baseada em tecnologias da Web (acessíveis através de navegadores) ou não, devem ser capazes de
acionar e obter resultados dos WS4PM.
7.2
Independência da plataforma de desenvolvimento da aplicação consumidora
SS13 Deve-se permitir que qualquer aplicação cliente, independente da plataforma sobre a qual foi
desenvolvida, acesse os métodos implementados nos WS4PM.
7.3
Utilização da XML
SS14 Os WS4PM devem utilizar a XML para a definição, transmissão, validação e interpretação de dados
entre aplicações.
7.4
Arquitetura em Camadas
SS15 Quando da implementação de aplicações que terão funcionalidades expostas com base nos WS4PM,
deve-se primar pelo seu desenvolvimento baseado em estilos de Arquitetura em Camadas.
8. Requisitos de Segurança
Esta seção trata os requisitos de segurança aplicáveis aos WS4PM.
8.1
Políticas de Autorização
SS16 Os WS4PM devem ser implementados primando-se pela utilização de Políticas de Autorização que
impeçam que pessoas não autorizadas acessem ou alterem informações que não lhe dizem respeito.
8.2
Autenticação e Segurança Digital
SS17 Para os WS4PM que exigirem segurança de informação, devem ser implementados mecanismos de
autenticação e segurança baseados em tecnologias de certificados e assinaturas digitais, como por exemplo:
certificados X.509 e bilhetes Kerberos.
9. Requisitos de Padrões Aplicáveis
Esta seção apresenta requisitos relacionados a padrões de desenvolvimento de software, a serem utilizados
na implementação dos WS4PM.
9.1
Padrões propostos pela W3C (World Wide Web Consortium).
SS18 Quando da implementação dos WS4PM sugere-se a observação dos padrões para Serviços Web
propostos pela W3C que podem ser acessados a partir de www.w3.org.
9.2
Padrões propostos pela WS-I (Web Services Interoperability).
SS19 Quando da implementação dos WS4PM sugere-se a observação dos padrões para Serviços Web
propostos pela WS-I que podem ser acessados a partir de www.ws-i.org.
Computação
Aeronáutica, 2003
226
Relação Analítica de Requisitos
Versão 1.0
Apêndice 6
WS4PM – Relação Analítica de Requisitos
Introdução
Este documento apresenta uma relação analítica de todos os requisitos especificados para os Serviços
Web Aplicáveis à Gestão de Projetos (Web Services For Project Management – WS4PM). Os itens dessa
relação estão agrupados por Tipo de Requisitos e para cada um deles é exibido:
•
O identificador do requisito. Atribuído pela ferramenta de software selecionada e utilizada para o
gerenciamento de requisitos, a Rational RequisitePro;
•
O título do requisito;
•
O tipo do requisito, conforme definido no Plano de Gerenciamento de Requisitos;
•
O texto do requisito;
•
Os atributos com seus respectivos valores, atribuídos numa análise inicial; e
•
A rastreabilidade (de/para) do requisito propiciando a visibilidade da origem e do impacto do
requisito na solução tecnológica proposta.
Vale salientar que alguns atributos dos requisitos têm seu valor definido ao longo de todo o projeto de
software, ou seja, alguns são definidos a priori e outros a posteriori. Dessa forma, é comum encontrar, dentre os
atributos dos requisitos constantes nessa relação, uma série de atributos com valores que ainda não foram
definidos.
228
Apêndice 6
Versão:
1.0
Data: 10/10/2003
FEAT1 Suporte aos Processos de Iniciação
Tipo de Requisito:Característica
Texto do Requisito:Os Serviços Web para Softwares de Apoio à Gestão de Projetos devem fornecer suporte
aos Processos de Iniciação definidos pelo PMI.
Atributos
Status : Aprovado
Classe : Funcional
Comentário :
Prioridade : Média
Rastrea de:
STRQ1 :Suporte às 9 (nove) Áreas de Conhecimento da Gestão de Projetos
STRQ2.1 :Suporte ao Grupo de Processos de Iniciação
Rastrea para:
FEAT1.1 Suporte ao Processo de Iniciação
Texto do Requisito:Os Serviços Web para Softwares de Gestão de Projetos devem suportar o Processo de
Iniciação de Projetos.
Atributos
Status : Aprovado
Classe : Funcional
Comentário :
Prioridade : Média
Rastrea de:
STRQ1.2 :Suporte à área de Gestão do Escopo
Rastrea para:
UC1 :Obtenção de Informações do Documento de Autorização do Projeto
UC2 :Registro de interesse ou comprometimento das Empresas Parceiras
UC3 :Obtenção de restrições e premissas definidas pela Proprietária
FEAT2 Suporte aos Processos de Planejamento
aos Processos de Planejamento definidos pelo PMI.
Atributos
Status : Aprovado
Classe : Funcional
Comentário :
Prioridade : Alta
Computação
Aeronáutica, 2003
229
Apêndice 6
Versão:
1.0
Data: 10/10/2003
Rastrea de:
STRQ2.2 :Suporte ao Grupo de Processos de Planejamento.
Rastrea para:
FEAT2.1 Suporte ao Processo de Planejamento do Escopo
Texto do Requisito:Os Serviços Web para Softwares de Apoio à Gestão de Projetos devem suportar o
Processo de Planejamento do Escopo de Projetos.
Atributos
Status : Aprovado
Classe : Funcional
Comentário :
Prioridade : Alta
Rastrea de:
Rastrea para:
UC4 :Obtenção da Descrição Sumária do Produto do Projeto
UC5 :Obtenção de Objetivos Macros do Projeto
UC6 :Obtenção da Lista Sumarizada dos componentes do Projeto
FEAT2.2 Suporte ao Processo de Detalhamento do Escopo
Processo de Detalhamento do Escopo de Projetos.
Atributos
Status : Aprovado
Classe : Funcional
Comentário :
Prioridade : Alta
Rastrea de:
Rastrea para:
UC7 :Acesso a Informações de elementos da WBS do Projeto
FEAT2.3 Suporte ao Processo de Definição das Atividades
Computação
Aeronáutica, 2003
230
Apêndice 6
Versão:
1.0
Data: 10/10/2003
Processo de Definição das Atividades de Projetos.
Atributos
Status : Aprovado
Classe : Funcional
Comentário :
Prioridade : Alta
Rastrea de:
STRQ1.3 :Suporte à Gestão de Prazos
Rastrea para:
FEAT2.4 Suporte ao Processo de Sequenciamento de Atividades
Processo de Sequenciamento de Atividades.
Atributos
Status : Aprovado
Classe : Funcional
Comentário :
Prioridade : Alta
Rastrea de:
Rastrea para:
UC8 :Registro de restrições de tempo para desenvolvimento de componentes
FEAT2.5 Suporte ao Processo de Estimativa de Duração das Atividades
Processo de Estimativa de Duração das Atividades de Projetos.
Atributos
Status : Aprovado
Classe : Funcional
Comentário :
Prioridade : Alta
Rastrea de:
Rastrea para:
UC9 :Definição da duração das atividades delegadas a Parceiras
Computação
Aeronáutica, 2003
231
Apêndice 6
Versão:
1.0
Data: 10/10/2003
FEAT2.6 Suporte ao Processo de Desenvolvimento do Cronograma
Processo de Desenvolvimento do Cronograma de Projetos.
Atributos
Status : Aprovado
Classe : Funcional
Comentário :
Prioridade : Alta
Rastrea de:
Rastrea para:
FEAT2.7 Suporte ao processo de Planejamento da Gestão de Riscos em Projetos
Processo de Planejamento da Gestão de Riscos em Projetos.
Atributos
Status : Aprovado
Classe : Funcional
Comentário :
Prioridade : Alta
Rastrea de:
STRQ1.8 :Suporte à área de Gestão de Riscos
Rastrea para:
UC10 :Registro de informações de auxílio ao planejamento da gestão de riscos
FEAT2.8 Suporte ao Processo de Planejamento de Recursos
Processo de Planejamento de Recursos de Projetos.
Atributos
Status : Aprovado
Classe : Funcional
Comentário :
Prioridade : Alta
Rastrea de:
STRQ1.4 :Suporte à área de Gestão de Custos
Rastrea para:
Computação
Aeronáutica, 2003
232
Apêndice 6
Versão:
1.0
Data: 10/10/2003
UC11 :Obtenção de informações sobre o componente a ser desenvolvido
FEAT2.9 Suporte ao Processo de Estimativas de Custo
Processo de Estimativas de Custo de Projetos.
Atributos
Status : Aprovado
Classe : Funcional
Comentário :
Prioridade : Alta
Rastrea de:
Rastrea para:
UC12 :Comunicação das estimativas de custo de componentes à Proprietária do Projeto
UC13 :Definição de uma unidade monetária para o Projeto
FEAT2.10 Suporte ao Processo de Orçamentação de Custos
Processo de Orçamentação de Custos de Projetos.
Atributos
Status : Aprovado
Classe : Funcional
Comentário :
Prioridade : Alta
Rastrea de:
Rastrea para:
UC14 :Comunicação das Orçamentações de Custo do desenvolvimento de componentes
FEAT2.11 Suporte ao Processo de Desenvolvimento do Plano de Projetos
Processo de Desenvolvimento do Plano de Projetos.
Atributos
Status : Aprovado
Classe : Funcional
Comentário :
Computação
Aeronáutica, 2003
233
Apêndice 6
Versão:
1.0
Data: 10/10/2003
Prioridade : Alta
Rastrea de:
STRQ1.1 :Suporte à área de Gestão da Integração
Rastrea para:
UC15 :Registro de Restrições, Premissas e Dados de Políticas Organizacionais de Parcerias do Projeto
UC16 :Acesso, por parte das Parceiras do Projeto, a elementos do Plano.
UC17 :Consulta a informações referentes a detalhes de suporte
FEAT2.12 Suporte ao Processo de Planejamento da Qualidade
Processo de Planejamento da Qualidade em Projetos.
Atributos
Status : Aprovado
Classe : Funcional
Comentário :
Prioridade : Alta
Rastrea de:
STRQ1.5 :Suporte à área de Gestão da Qualidade
Rastrea para:
UC18 :Consulta a Políticas de Qualidade da Proprietária do Projeto
UC19 :Obtenção da definição do Produto do Projeto
UC20 :Obtenção da definição do escopo do Produto do Projeto
UC21 :Obtenção de Padrões e Regulamentos do Projeto
UC22 :Informação de custos relativos ao Controle de Qualidade no desenvolvimento de Componentes
FEAT2.13 Suporte ao Processo de Planejamento Organizacional
Processo de Planejamento Organizacional.
Atributos
Status : Aprovado
Classe : Funcional
Comentário :
Prioridade : Alta
Rastrea de:
Computação
Aeronáutica, 2003
234
Apêndice 6
Versão:
1.0
Data: 10/10/2003
STRQ1.6 :Suporte à área de Recursos Humanos
Rastrea para:
FEAT2.14 Suporte ao Processo de Montagem da Equipe
Processo de Montagem da Equipe de Projetos.
Atributos
Status : Aprovado
Classe : Funcional
Comentário :
Prioridade : Alta
Rastrea de:
Rastrea para:
FEAT2.15 Suporte ao Processo de Planejamento da Comunicação em Projetos
Processo de Planejamento da Comunicação em Projetos.
Atributos
Status : Aprovado
Classe : Funcional
Comentário :
Prioridade : Alta
Rastrea de:
STRQ1.7 :Suporte à área de Gestão da Comunicação
Rastrea para:
UC23 :Registro de Requisitos de Comunicação
SS20 :Definição de um Portal para possibilitar a utilização de alguns Serviços Web
FEAT2.16 Suporte ao Processo de Identificação de Riscos
Processo de Identificação de Riscos em Projetos.
Atributos
Status : Aprovado
Classe : Funcional
Comentário :
Computação
Aeronáutica, 2003
235
Apêndice 6
Versão:
1.0
Data: 10/10/2003
Prioridade : Alta
Rastrea de:
Rastrea para:
UC24 :Registro de riscos relacionados a componentes
UC25 :Definição de gatilhos que disparam comunicados aos envolvidos, caso determinados marcos
não sejam atingidos
FEAT2.17 Suporte ao Processo de Análise Qualitativa de Riscos
Processo de Análise Qualitativa de Riscos em Projetos.
Atributos
Status : Aprovado
Classe : Funcional
Comentário :
Prioridade : Alta
Rastrea de:
Rastrea para:
UC26 :Obtenção de informações referentes à Classificação do Risco Global para o Projeto
UC27 :Obtenção da Lista de Riscos Prioritários para o projeto de componentes
UC28 :Obtenção de informações de itens da Lista de Riscos de componentes
UC29 :Obtenção de informações a respeito da tendência em resultados de Análise Qualitativa de
Riscos dos componentes
FEAT2.18 Suporte ao Processo de Análise Quantitativa de Riscos em Projetos
Processo de Análise Quantitativa de Riscos em Projetos.
Atributos
Status : Aprovado
Classe : Funcional
Comentário :
Prioridade : Alta
Rastrea de:
Rastrea para:
Computação
Aeronáutica, 2003
236
Apêndice 6
Versão:
1.0
Data: 10/10/2003
UC30 :Obtenção da Lista Priorizada de Riscos Quantificados dos Projetos de componentes
UC31 :Obtenção de resultados da Análise Probabilística dos Projetos de Componentes
UC32 :Obtenção da probabilidade de alcance dos objetivos de custo e tempo dos projetos de
componentes
UC33 :Obtenção das tendências de resultados da Análise Quantitativa dos riscos dos projetos de
componentes
FEAT2.19 Suporte ao Processo de Planejamento de Resposta a Riscos
Processo de Planejamento de Resposta a Riscos em Projetos.
Atributos
Status : Aprovado
Classe : Funcional
Comentário :
Prioridade : Alta
Rastrea de:
Rastrea para:
UC34 :Registro de riscos do projeto de componentes, potenciais para o projeto como um todo
FEAT2.20 Suporte ao Processo de Planejamento de Aquisições em Projetos
Processo de Planejamento de Aquisições em Projetos.
Atributos
Status : Aprovado
Classe : Funcional
Comentário :
Prioridade : Alta
Rastrea de:
STRQ1.9 :Suporte à área de Gestão de Aquisições
Rastrea para:
UC35 :Conhecimento mútuo da saúde financeira de parceiros de projetos
FEAT2.21 Suporte ao Processo de Preparação de Aquisições em Projetos
Processo de Preparação de Aquisições em Projetos.
Computação
Aeronáutica, 2003
237
Apêndice 6
Versão:
1.0
Data: 10/10/2003
Atributos
Status : Aprovado
Classe : Funcional
Comentário :
Prioridade : Alta
Rastrea de:
Rastrea para:
FEAT3 Suporte aos Processos de Execução
aos Processos de Execução definidos pelo PMI.
Atributos
Status : Aprovado
Classe : Funcional
Comentário :
Prioridade : Alta
Rastrea de:
STRQ2.3 :Suporte ao Grupo de Processos de Execução
Rastrea para:
FEAT3.1 Suporte ao Processo de Execução do Plano do Projeto
Processo de Execução do Plano do Projeto.
Atributos
Status : Aprovado
Classe : Funcional
Comentário :
Prioridade : Alta
Rastrea de:
Rastrea para:
UC36 :Registro e Consulta do trabalho executado
UC37 :Registro de Solicitações de Mudança
Computação
Aeronáutica, 2003
238
Apêndice 6
Versão:
1.0
Data: 10/10/2003
FEAT3.2 Suporte ao Processo de Garantia da Qualidade
Processo de Garantia da Qualidade em Projetos.
Atributos
Status : Aprovado
Classe : Funcional
Comentário :
Prioridade : Alta
Rastrea de:
Rastrea para:
UC38 :Relato dos resultados de medição do controle de qualidade dos componentes
FEAT3.3 Suporte ao Processo de Desenvolvimento da Equipe de Projeto
Processo de Desenvolvimento da Equipe de Projeto.
Atributos
Status : Aprovado
Classe : Funcional
Comentário :
Prioridade : Alta
Rastrea de:
Rastrea para:
FEAT3.4 Suporte ao Processo de dsitribuição das Informações
Processo de Distribuição de Informações em Projetos.
Atributos
Status : Aprovado
Classe : Funcional
Comentário :
Prioridade : Alta
Rastrea de:
Rastrea para:
Computação
Aeronáutica, 2003
239
Apêndice 6
Versão:
1.0
Data: 10/10/2003
FEAT3.5 Suporte ao Processo de Pedido de Propostas
Processo de Pedidos de Propostas para aquisições em Projetos.
Atributos
Status : Aprovado
Classe : Funcional
Comentário :
Prioridade : Alta
Rastrea de:
Rastrea para:
FEAT3.6 Suporte ao Processo de Seleção de Fornecedores
Processo de Seleção de Fornecedores para aquisições em Projetos.
Atributos
Status : Aprovado
Classe : Funcional
Comentário :
Prioridade : Alta
Rastrea de:
Rastrea para:
FEAT3.7 Suporte ao Processo de Administração de Contratos
Processo de Administração de Contratos em Projetos.
Atributos
Status : Aprovado
Classe : Funcional
Comentário :
Prioridade : Alta
Rastrea de:
Rastrea para:
Computação
Aeronáutica, 2003
240
Apêndice 6
Versão:
1.0
Data: 10/10/2003
FEAT4 Suporte aos Processos de Controle
Texto do Requisito:Os serviços Web devem fornecer suporte aos Processos de Controle definidos pelo PMI.
Atributos
Status : Aprovado
Classe : Funcional
Comentário :
Prioridade : Alta
Rastrea de:
STRQ2.4 :Suporte ao Grupo de Processos de Controle
Rastrea para:
FEAT4.1 Suporte ao Processo de Relato de Desempenho de Projetos
Processo de Relato de Desempenho de Projetos.
Atributos
Status : Aprovado
Classe : Funcional
Comentário :
Prioridade : Alta
Rastrea de:
Rastrea para:
UC39 :Obtenção de dados de relatórios de situação, progresso e previsões gerados pelas Empresas
Parceiras
UC40 :Registro de dados referentes à análise de tendências, variações e valor obtido dos projetos de
componentes
UC41 :Registro de requisições de Mudança, mediante a análise de desempenho do Projeto.
FEAT4.2 Suporte ao Processo de Controle Integrado de Mudanças em Projetos
Processo de Controle Integrado de Mudanças em Projetos.
Atributos
Status : Aprovado
Classe : Funcional
Comentário :
Computação
Aeronáutica, 2003
241
Apêndice 6
Versão:
1.0
Data: 10/10/2003
Prioridade : Alta
Rastrea de:
Rastrea para:
UC42 :Atualizações no Plano do Projeto
FEAT4.3 Suporte ao Processo de Verificação do Escopo de Projetos
Processo de Verificação de Escopo de Projetos.
Atributos
Status : Aprovado
Classe : Funcional
Comentário :
Prioridade : Alta
Rastrea de:
Rastrea para:
UC43 :Registro de aceitação do escopo dos componentes
FEAT4.4 Suporte ao Processo de Controle de Mudanças do Escopo de Projetos
Processo de Controle de Mudanças do Escopo de Projetos.
Atributos
Status : Aprovado
Classe : Funcional
Comentário :
Prioridade : Alta
Rastrea de:
Rastrea para:
UC44 :Registro das Informações que comporão relatórios de desempenho
UC45 :Registro de requisições de mudança no Escopo do Projeto
UC46 :Comunicação de mudanças sugeridas, em aprovação e aprovadas, em relação escopo do projeto
FEAT4.5 Suporte ao Processo de Controle do Cronograma de Projetos
Computação
Aeronáutica, 2003
242
Apêndice 6
Versão:
1.0
Data: 10/10/2003
Processo de Controle do Cronograma de Projetos.
Atributos
Status : Aprovado
Classe : Funcional
Comentário :
Prioridade : Alta
Rastrea de:
Rastrea para:
UC47 :Comunicação à Proprietária do Projeto de atualizações no cronograma do projeto de
componentes
UC48 :Comunicação às Empresas Parceiras de atualizações feitas no cronograma do projeto
FEAT4.6 Suporte ao Processo de Controle de Custos de Projetos
Processo de Controle de Custos de Projetos.
Atributos
Status : Aprovado
Classe : Funcional
Comentário :
Prioridade : Alta
Rastrea de:
Rastrea para:
UC49 :Relato do Desempenho do Projeto de Componentes à Proprietária do Projeto
UC50 :Obtenção, por parte das Empresas Parceiras do Projeto, de informações sobre a Análise de
Valor Obtido do Projeto de Larga Escala
FEAT4.7 Suporte ao Processo de Controle da Qualidade em Projetos
Processo de Controle da Qualidade em Projetos.
Atributos
Status : Aprovado
Classe : Funcional
Comentário :
Computação
Aeronáutica, 2003
243
Apêndice 6
Versão:
1.0
Data: 10/10/2003
Prioridade : Alta
Rastrea de:
Rastrea para:
UC51 :Obtenção de informações referentes a Padrões de Qualidade estabelecidos pela Proprietária do
Projeto
FEAT4.8 Suporte ao Processo de Controle e Monitoração de Riscos em Projetos
Processo de Controle e Monitoração de Riscos em Projetos.
Atributos
Status : Aprovado
Classe : Funcional
Comentário :
Prioridade : Alta
Rastrea de:
Rastrea para:
UC52 :Obtenção de valores referentes ao controle e monitoramento de riscos do projeto de um
componente
FEAT5 Suporte aos Processos de Encerramento
aos Processos de Encerramento definidos pelo PMI.
Atributos
Status : Aprovado
Classe : Funcional
Comentário :
Prioridade : Baixa
Rastrea de:
STRQ2.5 :Suporte ao Grupo de Processos de Encerramento
Rastrea para:
FEAT5.1 Suporte ao Processo de Encerramento de Contratos
Texto do Requisito:Os WS4PM devem suportar o Processo de Encerramento de Contratos.
Atributos
Computação
Aeronáutica, 2003
244
Apêndice 6
Versão:
1.0
Data: 10/10/2003
Status : Aprovado
Classe : Funcional
Comentário :
Prioridade : Baixa
Rastrea de:
Rastrea para:
UC53 :Registro de encerramento de contrato entre Proprietária e Parceira do Projeto
FEAT5.2 Suporte ao Processo de Encerramento Administrativo de Projetos
Texto do Requisito:Os WS4PM devem suportar o Processo de Encerramento Administrativo de Projetos.
Atributos
Status : Aprovado
Classe : Funcional
Comentário :
Prioridade : Baixa
Rastrea de:
Rastrea para:
UC54 :Registro automático do percentual de completude de um elemento da WBS do Projeto
FEAT6 Permitir a customização de endereços e outros dados de identificação dos serviços
Texto do Requisito:Na implementação dos clientes dos WS4PM deve-se primar pela parametrização,
possibilitando a customização de endereços, nomes dos serviços e outros dados que podem mudar em função da
escolha de parceiros de projetos.
Atributos
Status : Aprovado
Classe : Não Funcional
Comentário :
Prioridade : Alta
Rastrea de:
STRQ3 :Facilidades na utilização
Rastrea para:
SS2 :Parametrização de informações de acesso aos WS4PM
Computação
Aeronáutica, 2003
245
Apêndice 6
Versão:
1.0
Data: 10/10/2003
FEAT7 Alta Disponibilidade
Texto do Requisito:Os Serviços Web aplicáveis à Gestão de Projetos devem estar disponíveis para consumo
independente de dia e horário.
Atributos
Status : Aprovado
Comentário :
Prioridade : Alta
Rastrea de:
STRQ5 :Alta disponibilidade
Rastrea para:
SS8 :Disponibilidade 24x7
FEAT8 Independência de Plataforma
Texto do Requisito:Os WS4PM, por se basearem na tecnologia de Serviços Web, podem ser acessados por
aplicações desenvolvidas em plataformas diferentes daquela que foi utilizada para implementá-los.
Atributos
Status : Aprovado
Comentário :
Prioridade : Alta
Rastrea de:
Rastrea para:
SS13 :Independência da plataforma de desenvolvimento da aplicação consumidora
FEAT9 Acessibilidade via rede
Texto do Requisito:O uso da tecnologia de Serviços Web permite que os WS4PM sejam acessados através
da rede mundial de computadores (Internet).
Atributos
Status : Aprovado
Comentário :
Prioridade : Alta
Rastrea de:
Computação
Aeronáutica, 2003
246
Apêndice 6
Versão:
1.0
Data: 10/10/2003
Rastrea para:
SS5 :Conexão a uma rede (Internet ou Intranet)
SS7 :Transposição de Firewalls
FEAT10 Conformidade com Padrões
Texto do Requisito:Os WS4PM são desenvolvidos conforme os padrões estabelecidos e propostos pela W3C
(World Wide Web Consortium) e WS-I (Web Services Interoperability).
Atributos
Status : Aprovado
Comentário :
Prioridade : Alta
Rastrea de:
STRQ6 :Conformidade com Padrões
Rastrea para:
SS4 :Descrição de Web Services em WSDL
SS14 :Utilização da XML
SS15 :Arquitetura em Camadas
SS18 :Padrões propostos pela W3C (World Wide Web Consortium).
SS19 :Padrões propostos pela WS-I (Web Services Interoperability).
FEAT11 Facilidades para o Estabelecimento de Parcerias de Projetos
Texto do Requisito:Os WS4PM de cada empresa podem ser registrados em Servidores UDDI públicos ou
privados agilizando o processo de estabelecimento de parcerias de projetos, pois estas podem conhecer,
mutuamente, informações sobre seus negócios e os WS4PM que cada uma disponibiliza.
Atributos
Status : Aprovado
Comentário :
Prioridade : Alta
Rastrea de:
Rastrea para:
SS3 :Registro do Negócio e Serviços da Empresa em Servidores de Serviços UDDI
SS6 :Interação mínina dos usuários
Computação
Aeronáutica, 2003
247
Apêndice 6
Versão:
1.0
Data: 10/10/2003
SS11 :Acessos Simultâneos
SS12 :Independência de interface na porção Consumidora
FEAT12 Confiabilidade e Segurança no Processamento
Texto do Requisito:Os WS4PM são desenvolvidos levando-se em consideração aspectos e confiabilidade e
segurança no processamento de informações.
Atributos
Status : Aprovado
Comentário :
Prioridade : Alta
Rastrea de:
STRQ4 :Confiabilidade
Rastrea para:
SS1 :Log de Erros
SS9 :Controle de Transações
SS10 :Tempo de Resposta
SS16 :Políticas de Autorização
SS17 :Autenticação e Segurança Digital
UC1 Obtenção de Informações do Documento de Autorização do Projeto
Tipo de Requisito:Casos de Uso
Texto do Requisito:Ra1.1 – É necessário um serviço que possibilite às Empresas Parceiras do Projeto e
Envolvidos (stakeholders) obterem informações constantes no Documento de Autorização do Projeto (Project
Charter) elaborado pela Empresa Líder do Projeto.
Atributos
Prioridade : Alta
Status : Aprovado
Esforço :
Risco :
Estabilidade :
Dificuldade :
Atribuido a :
Afeta a Arquitetura :
Comentário :
Computação
Aeronáutica, 2003
248
Apêndice 6
Versão:
1.0
Data: 10/10/2003
Release Alvo :
Rastrea de:
FEAT1.1 :Suporte ao Processo de Iniciação
Rastrea para:
UC2 Registro de interesse ou comprometimento das Empresas Parceiras
Texto do Requisito:Ra1.2 – É necessário um serviço que possibilite o registro de manifestação de interesse
ou comprometimento em participar do projeto por parte das Empresas Parceiras da Empresa Líder do Projetos;
e
Atributos
Prioridade : Baixa
Status : Aprovado
Esforço :
Risco :
Estabilidade :
Dificuldade :
Atribuido a :
Comentário :
Release Alvo :
Rastrea de:
Rastrea para:
UC3 Obtenção de restrições e premissas definidas pela Proprietária
Texto do Requisito:Ra1.3 – É necessário um serviço que permita às Empresas Parceiras do Projeto e
Envolvidos terem acesso a restrições e premissas definidas pela Empresa Líder do Projeto.
Atributos
Prioridade : Alta
Status : Aprovado
Esforço :
Risco :
Estabilidade :
Dificuldade :
Computação
Aeronáutica, 2003
249
Apêndice 6
Versão:
1.0
Data: 10/10/2003
Atribuido a :
Comentário :
Release Alvo :
Rastrea de:
Rastrea para:
UC4 Obtenção da Descrição Sumária do Produto do Projeto
Texto do Requisito:Rb1.1 – É necessário um serviço que possibilite às Empresas Parceiras do Projeto
obterem a descrição sumária do produto a ser desenvolvido;
Atributos
Prioridade : Alta
Status : Aprovado
Esforço :
Risco :
Estabilidade :
Dificuldade :
Atribuido a :
Comentário :
Release Alvo :
Rastrea de:
FEAT2.1 :Suporte ao Processo de Planejamento do Escopo
Rastrea para:
UC5 Obtenção de Objetivos Macros do Projeto
Texto do Requisito:Rb1.2 - É necessário um serviço que possibilite às Empresas Parceiras do Projeto
obterem os objetivos macros do projeto a ser desenvolvido;
Atributos
Prioridade : Alta
Status : Aprovado
Esforço :
Computação
Aeronáutica, 2003
250
Apêndice 6
Versão:
1.0
Data: 10/10/2003
Risco :
Estabilidade :
Dificuldade :
Atribuido a :
Comentário :
Release Alvo :
Rastrea de:
Rastrea para:
UC6 Obtenção da Lista Sumarizada dos componentes do Projeto
Texto do Requisito:Rb1.3 - É necessário um serviço que possibilite às Empresas Parceiras do Projeto
obterem uma lista sumarizada dos componentes do projeto, identificando aqueles que lhe cabem.
Atributos
Prioridade : Baixa
Status : Aprovado
Esforço :
Risco :
Estabilidade :
Dificuldade :
Atribuido a :
Comentário :
Release Alvo :
Rastrea de:
Rastrea para:
UC7 Acesso a Informações de elementos da WBS do Projeto
Texto do Requisito:Rb2.1 – É necessário um serviço que permita às Empresas Parceiras, acessarem
informações referentes a elementos da WBS do projeto definidos pela Empresa Líder do Projeto.
Atributos
Prioridade : Alta
Computação
Aeronáutica, 2003
251
Apêndice 6
Versão:
1.0
Data: 10/10/2003
Status : Aprovado
Esforço :
Risco :
Estabilidade :
Dificuldade :
Atribuido a :
Comentário :
Release Alvo :
Rastrea de:
FEAT2.2 :Suporte ao Processo de Detalhamento do Escopo
Rastrea para:
UC8 Registro de restrições de tempo para desenvolvimento de componentes
Texto do Requisito:Rb4.1 – É necessário um serviço que permita às Empresas Parceiras registrarem, junto às
Empresas Proprietárias de Projetos, restrições em termos de início e término de atividades para o
desenvolvimento do subproduto que lhe foi delegado.
Atributos
Prioridade : Alta
Status : Aprovado
Esforço : **
Risco :
Estabilidade :
Dificuldade :
Atribuido a :
Comentário :
Release Alvo :
Rastrea de:
FEAT2.4 :Suporte ao Processo de Sequenciamento de Atividades
Rastrea para:
Computação
Aeronáutica, 2003
252
Apêndice 6
Versão:
1.0
Data: 10/10/2003
UC9 Definição da duração das atividades delegadas a Parceiras
Texto do Requisito:Rb5.1 – É necessário um serviço para propiciar às Empresas Parceiras a capacidade de
definirem a duração das atividades que lhes forem delegadas, ou seja, a Empresa Parceira do Projeto que
fabricará a asa de um novo modelo de aeronave, poderá informar, após a elaboração do projeto desta, o tempo
estimado de duração das atividades de “construção da asa” e “integração da asa à fuselagem”.
Atributos
Prioridade : Alta
Status : Aprovado
Esforço : **
Risco :
Estabilidade :
Dificuldade :
Atribuido a :
Comentário :
Release Alvo :
Rastrea de:
FEAT2.5 :Suporte ao Processo de Estimativa de Duração das Atividades
Rastrea para:
UC10 Registro de informações de auxílio ao planejamento da gestão de riscos
Texto do Requisito:Rb7.1 - É necessário um serviço que permita às Empresas Parceiras do Projeto e outros
stakeholders registrarem junto à Empresa Líder do Projeto informações que contribuirão para planejamento da
gestão de riscos.
Atributos
Prioridade : Média
Status : Aprovado
Esforço :
Risco :
Estabilidade :
Dificuldade : Média
Atribuido a :
Comentário :
Computação
Aeronáutica, 2003
253
Apêndice 6
Versão:
1.0
Data: 10/10/2003
Release Alvo :
Rastrea de:
FEAT2.7 :Suporte ao processo de Planejamento da Gestão de Riscos em Projetos
Rastrea para:
UC11 Obtenção de informações sobre o componente a ser desenvolvido
Texto do Requisito:Rb8.1 - É necessário um serviço para propiciar às Empresas Parceiras a capacidade de
obter dados do componente que esta deverá desenvolver incluindo a estimativa de duração apontada pela
Atributos
Prioridade : Alta
Status : Aprovado
Esforço :
Risco :
Estabilidade :
Dificuldade :
Atribuido a :
Comentário :
Release Alvo :
Rastrea de:
FEAT2.8 :Suporte ao Processo de Planejamento de Recursos
Rastrea para:
UC12 Comunicação das estimativas de custo de componentes à Proprietária do Projeto
Texto do Requisito:Rb9.1 – É necessário um serviço que possibilite às Empresas Parceiras comunicarem à
Empresa Líder do Projeto as estimativas de custo de seu componente.
Atributos
Prioridade : Média
Status : Aprovado
Esforço :
Risco :
Estabilidade :
Dificuldade :
Computação
Aeronáutica, 2003
254
Apêndice 6
Versão:
1.0
Data: 10/10/2003
Atribuido a :
Comentário :
Release Alvo :
Rastrea de:
FEAT2.9 :Suporte ao Processo de Estimativas de Custo
Rastrea para:
UC13 Definição de uma unidade monetária para o Projeto
Texto do Requisito:Rb9.2 - É necessário definir uma unidade monetária comum para os envolvidos no
projeto, que podem estar em partes distintas do mundo, e portanto, possuem moedas locais diferentes.
Atributos
Prioridade : Média
Status : Aprovado
Esforço :
Risco :
Estabilidade :
Dificuldade :
Atribuido a :
Comentário :
Release Alvo :
Rastrea de:
Rastrea para:
UC14 Comunicação das Orçamentações de Custo do desenvolvimento de componentes
Texto do Requisito:Rb10.1 – É necessário um serviço que possibilite às Empresas Parceiras comunicarem à
Empresa Líder do Projeto as orçamentações de custo de desenvolvimento do componente que lhe foi delegado.
Atributos
Prioridade : Alta
Status : Aprovado
Esforço :
Risco :
Computação
Aeronáutica, 2003
255
Apêndice 6
Versão:
1.0
Data: 10/10/2003
Estabilidade :
Dificuldade :
Atribuido a :
Comentário :
Release Alvo :
Rastrea de:
FEAT2.10 :Suporte ao Processo de Orçamentação de Custos
Rastrea para:
UC15 Registro de Restrições, Premissas e Dados de Políticas Organizacionais de Parcerias do
Projeto
Texto do Requisito:Rb11.1 – É necessário um serviço que possibilite às Empresas Parceiras registrarem
restrições, premissas e dados de suas políticas organizacionais que sejam relevantes para a composição do Plano
do Projeto da Empresa Líder do Projeto.
Atributos
Prioridade : Baixa
Status : Aprovado
Esforço :
Risco :
Estabilidade :
Dificuldade :
Atribuido a :
Comentário :
Release Alvo :
Rastrea de:
FEAT2.11 :Suporte ao Processo de Desenvolvimento do Plano de Projetos
Rastrea para:
UC16 Acesso, por parte das Parceiras do Projeto, a elementos do Plano.
Texto do Requisito:Rb11.2 – É necessário um serviço que permita o acesso, por parte das Empresas
Parceiras, a elementos do Plano do Projeto.
Atributos
Computação
Aeronáutica, 2003
256
Apêndice 6
Versão:
1.0
Data: 10/10/2003
Prioridade : Alta
Status : Aprovado
Esforço :
Risco :
Estabilidade :
Dificuldade :
Atribuido a :
Comentário :
Release Alvo :
Rastrea de:
Rastrea para:
UC17 Consulta a informações referentes a detalhes de suporte
Texto do Requisito:Rb11.3 – É necessário um serviço que possibilite às Empresas Parceiras realizarem
consultas a porções de informações referentes a detalhes de suporte como documentação sobre padrões
relevantes, documentação técnica, etc.
Atributos
Prioridade : Média
Status : Aprovado
Esforço :
Risco :
Estabilidade :
Dificuldade :
Atribuido a :
Comentário :
Release Alvo :
Rastrea de:
Rastrea para:
Computação
Aeronáutica, 2003
257
Apêndice 6
Versão:
1.0
Data: 10/10/2003
UC18 Consulta a Políticas de Qualidade da Proprietária do Projeto
Texto do Requisito:Rb12.1 – É necessário um serviço que possibilite às Empresas Parceiras consultarem
políticas de qualidade definidas pela Empresa Líder do Projeto.
Atributos
Prioridade : Média
Status : Aprovado
Esforço :
Risco :
Estabilidade :
Dificuldade :
Atribuido a :
Comentário :
Release Alvo :
Rastrea de:
FEAT2.12 :Suporte ao Processo de Planejamento da Qualidade
Rastrea para:
UC19 Obtenção da definição do Produto do Projeto
Texto do Requisito:Rb12.2 – É necessário um serviço que possibilite às Empresas Parceiras obterem a
definição do produto feita pela Empresa Líder do Projeto.
Atributos
Prioridade : Alta
Status : Aprovado
Esforço :
Risco :
Estabilidade :
Dificuldade :
Atribuido a :
Comentário :
Release Alvo :
Computação
Aeronáutica, 2003
258
Apêndice 6
Versão:
1.0
Data: 10/10/2003
Rastrea de:
Rastrea para:
UC20 Obtenção da definição do escopo do Produto do Projeto
Texto do Requisito:Rb12.3 – É necessário um serviço que possibilite às Empresas Parceiras obterem a
definição do escopo do produto feita pela Empresa Líder do Projeto.
Atributos
Prioridade : Alta
Status : Aprovado
Esforço :
Risco :
Estabilidade :
Dificuldade :
Atribuido a :
Comentário :
Release Alvo :
Rastrea de:
Rastrea para:
UC21 Obtenção de Padrões e Regulamentos do Projeto
Texto do Requisito:Rb12.4 – É necessário um serviço que possibilite às Empresas Parceiras obterem os
padrões e regulamentos definidos pela Empresa Proprietário do Projeto.
Atributos
Prioridade : Alta
Status : Aprovado
Esforço :
Risco :
Estabilidade :
Dificuldade :
Atribuido a :
Computação
Aeronáutica, 2003
259
Apêndice 6
Versão:
1.0
Data: 10/10/2003
Comentário :
Release Alvo :
Rastrea de:
Rastrea para:
UC22 Informação de custos relativos ao Controle de Qualidade no desenvolvimento de
Componentes
Texto do Requisito:Rb12.5 – É necessário um serviço que possibilite às Empresas Parceiras informarem à
Empresa Líder do Projeto, os custos relativos ao controle de qualidade de seu componente para que essa possa
obter o custo total da qualidade do projeto.
Atributos
Prioridade : Baixa
Status : Aprovado
Esforço :
Risco :
Estabilidade :
Dificuldade :
Atribuido a :
Comentário :
Release Alvo :
Rastrea de:
Rastrea para:
UC23 Registro de Requisitos de Comunicação
Texto do Requisito:Rb15.1 – É necessário um serviço que possibilite à Proprietária do Projeto e às Empresas
Parceiras registrarem seus requisitos de comunicação, ou seja, que informações eles esperam um do outro.
Atributos
Prioridade : Baixa
Status : Aprovado
Esforço :
Risco :
Computação
Aeronáutica, 2003
260
Apêndice 6
Versão:
1.0
Data: 10/10/2003
Estabilidade :
Dificuldade :
Atribuido a :
Comentário :
Release Alvo :
Rastrea de:
FEAT2.15 :Suporte ao Processo de Planejamento da Comunicação em Projetos
Rastrea para:
UC24 Registro de riscos relacionados a componentes
Texto do Requisito:Rb16.1 – É necessário um serviço que permita às Empresas Parceiras registrarem riscos
relacionados a seu subproduto que podem comprometer o desempenho do projeto como um todo, levando tal
informação a conhecimento da Empresa Líder do Projeto.
Atributos
Prioridade : Alta
Status : Aprovado
Esforço :
Risco :
Estabilidade :
Dificuldade :
Atribuido a :
Comentário :
Release Alvo :
Rastrea de:
FEAT2.16 :Suporte ao Processo de Identificação de Riscos
Rastrea para:
UC25 Definição de gatilhos que disparam comunicados aos envolvidos, caso determinados
marcos não sejam atingidos
Texto do Requisito:Rb16.2 - Podem ser definidos gatilhos que podem ser disparados caso marcos
intermediários definidos não sejam atingidos, advertindo a equipe do projeto de um atraso eminente no projeto.
Alguns marcos intermediários podem ser definidos nas Empresas Parceiras e gatilhos podem ser associados a
eles de forma que advertências lhes são reportadas e até reportadas à Proprietária do Projeto automaticamente.
Computação
Aeronáutica, 2003
261
Apêndice 6
Versão:
1.0
Data: 10/10/2003
Atributos
Prioridade : Alta
Status : Aprovado
Esforço :
Risco :
Estabilidade :
Dificuldade :
Atribuido a :
Comentário :
Release Alvo :
Rastrea de:
Rastrea para:
UC26 Obtenção de informações referentes à Classificação do Risco Global para o Projeto
Texto do Requisito:Rb17.1 – É necessário um serviço que permita o acesso dos envolvidos num projeto a
informações referentes à classificação dos riscos globais para o projeto.
Atributos
Prioridade : Média
Status : Aprovado
Esforço :
Risco :
Estabilidade :
Dificuldade :
Atribuido a :
Comentário :
Release Alvo :
Rastrea de:
FEAT2.17 :Suporte ao Processo de Análise Qualitativa de Riscos
Rastrea para:
Computação
Aeronáutica, 2003
262
Apêndice 6
Versão:
1.0
Data: 10/10/2003
UC27 Obtenção da Lista de Riscos Prioritários para o projeto de componentes
Texto do Requisito:Rb17.2 – É necessário um serviço que possibilite o acesso, por parte da Empresa
Propritária do Projeto, à lista de riscos prioritários das Empresas Parceiras do Projeto;
Atributos
Prioridade : Alta
Status : Aprovado
Esforço :
Risco :
Estabilidade :
Dificuldade :
Atribuido a :
Comentário :
Release Alvo :
Rastrea de:
Rastrea para:
UC28 Obtenção de informações de itens da Lista de Riscos de componentes
Texto do Requisito:Rb17.3 – É necessário um serviço que permita o acesso, por parte da Empresa Líder do
Projeto, a informações referentes a itens da Lista de Riscos das Empresas Parceiras para análise e
gerenciamento adicionais; e
Atributos
Prioridade : Média
Status : Aprovado
Esforço :
Risco :
Estabilidade :
Dificuldade :
Atribuido a :
Comentário :
Release Alvo :
Computação
Aeronáutica, 2003
263
Apêndice 6
Versão:
1.0
Data: 10/10/2003
Rastrea de:
Rastrea para:
UC29 Obtenção de informações a respeito da tendência em resultados de Análise Qualitativa
de Riscos dos componentes
Texto do Requisito:Rb17.4 - É necessário um serviço que permita à Empresa Líder do Projeto obter
informações a respeito da tendência em resultados da Análise Qualitativa de Riscos dos componentes delegados
a Empresas Parceiras do Projeto.
Atributos
Prioridade : Média
Status : Aprovado
Esforço :
Risco :
Estabilidade :
Dificuldade :
Atribuido a :
Comentário :
Release Alvo :
Rastrea de:
Rastrea para:
UC30 Obtenção da Lista Priorizada de Riscos Quantificados dos Projetos de componentes
Texto do Requisito:Rb18.1 – É necessário um serviço que permita à Empresa Líder do Projeto obter a lista
priorizada dos riscos quantificados dos projetos de componentes delegados a Empresas Parceiras;
Atributos
Prioridade : Média
Status : Aprovado
Esforço :
Risco :
Estabilidade :
Dificuldade :
Computação
Aeronáutica, 2003
264
Apêndice 6
Versão:
1.0
Data: 10/10/2003
Atribuido a :
Comentário :
Release Alvo :
Rastrea de:
FEAT2.18 :Suporte ao Processo de Análise Quantitativa de Riscos em Projetos
Rastrea para:
UC31 Obtenção de resultados da Análise Probabilística dos Projetos de Componentes
Texto do Requisito:Rb18.2 – É necessário um serviço que permita à Proprietária do Projeto obter resultados
da Análise Probabilística dos projetos de componentes delegados a Empresas Parceiras;
Atributos
Prioridade : Baixa
Status : Aprovado
Esforço :
Risco :
Estabilidade :
Dificuldade :
Atribuido a :
Comentário :
Release Alvo :
Rastrea de:
Rastrea para:
UC32 Obtenção da probabilidade de alcance dos objetivos de custo e tempo dos projetos de
componentes
Texto do Requisito:Rb18.3 – É necessário um serviço que permita à Empresa Líder do Projeto obter a
probabilidade de se alcançar os objetivos de custo e de tempo dos projetos de componentes sob a
responsabilidade de Empresas Parceiras do Projeto; e
Atributos
Prioridade : Baixa
Status : Aprovado
Esforço :
Computação
Aeronáutica, 2003
265
Apêndice 6
Versão:
1.0
Data: 10/10/2003
Risco :
Estabilidade :
Dificuldade :
Atribuido a :
Comentário :
Release Alvo :
Rastrea de:
Rastrea para:
UC33 Obtenção das tendências de resultados da Análise Quantitativa dos riscos dos projetos
de componentes
Texto do Requisito:Rb18.4 – É necessário um serviço que permita à Empresa Líder do Projeto obter as
tendências no resultado da análise quantitativa dos riscos dos projetos de componentes sob responsabilidade de
Empresas Parceiras.
Atributos
Prioridade : Baixa
Status : Aprovado
Esforço :
Risco :
Estabilidade :
Dificuldade :
Atribuido a :
Comentário :
Release Alvo :
Rastrea de:
Rastrea para:
UC34 Registro de riscos do projeto de componentes, potenciais para o projeto como um todo
Computação
Aeronáutica, 2003
266
Apêndice 6
Versão:
1.0
Data: 10/10/2003
Texto do Requisito:Rb19.1 – É necessário um serviço que permita às Empresas Parceiras do Projeto
registrarem, junto à Empresa Líder do Projeto, informações sobre riscos do projeto que estão desenvolvendo e
que são considerados riscos potenciais para o Projeto de Larga Escala como um todo
Atributos
Prioridade : Alta
Status : Aprovado
Esforço :
Risco :
Estabilidade :
Atribuido a :
Comentário :
Release Alvo :
Rastrea de:
FEAT2.19 :Suporte ao Processo de Planejamento de Resposta a Riscos
Rastrea para:
UC35 Conhecimento mútuo da saúde financeira de parceiros de projetos
Texto do Requisito:Rb20.1 – É necessário um serviço que permita aos parceiros de projetos (Empresa Líder
do Projeto e Empresa Parceira do Projeto) conhecerem, mutuamente, sua “saúde financeira”.
Atributos
Prioridade : Baixa
Status : Aprovado
Esforço :
Risco :
Estabilidade :
Dificuldade :
Atribuido a :
Comentário :
Release Alvo :
Rastrea de:
FEAT2.20 :Suporte ao Processo de Planejamento de Aquisições em Projetos
Computação
Aeronáutica, 2003
267
Apêndice 6
Versão:
1.0
Data: 10/10/2003
Rastrea para:
UC36 Registro e Consulta do trabalho executado
Texto do Requisito:Rc1.1 – É necessário um serviço que permita o registro e consulta a resultados do
trabalho executado tanto na Empresa Líder do Projeto quanto nas Empresas Parceiras do Projeto, oferecendo
visibilidade a quem de direito.
Atributos
Prioridade : Média
Status : Aprovado
Esforço :
Risco :
Estabilidade :
Dificuldade :
Atribuido a :
Comentário :
Release Alvo :
Rastrea de:
FEAT3.1 :Suporte ao Processo de Execução do Plano do Projeto
Rastrea para:
UC37 Registro de Solicitações de Mudança
Texto do Requisito:Rc1.2 – É necessário um serviço que permita tanto à Empresa Líder do Projeto quanto às
Empresas Parceiras registrarem e comunicarem solicitações de mudanças, disparando gatilhos de comunicação
para os envolvidos.
Atributos
Prioridade : Alta
Status : Aprovado
Esforço :
Risco :
Estabilidade :
Dificuldade :
Atribuido a :
Computação
Aeronáutica, 2003
268
Apêndice 6
Versão:
1.0
Data: 10/10/2003
Comentário :
Release Alvo :
Rastrea de:
Rastrea para:
UC38 Relato dos resultados de medição do controle de qualidade dos componentes
Texto do Requisito:Rc2.1 – É necessário um serviço que possibilite às Empresas Parceiras do Projeto
relatarem de forma automatizada os resultados de medição do controle de qualidade do componente que ela está
desenvolvendo.
Atributos
Prioridade : Alta
Status : Aprovado
Esforço :
Risco :
Estabilidade :
Dificuldade :
Atribuido a :
Comentário :
Release Alvo :
Rastrea de:
FEAT3.2 :Suporte ao Processo de Garantia da Qualidade
Rastrea para:
UC39 Obtenção de dados de relatórios de situação, progresso e previsões gerados pelas
Empresas Parceiras
Texto do Requisito:Rd1.1 – É necessário um serviço que permita à Empresa Líder do Projeto obter dados de
relatórios de situação, progresso e previsões gerados pelas Empresas Parceiras do Projeto.
Atributos
Prioridade : Alta
Status : Aprovado
Esforço :
Risco :
Computação
Aeronáutica, 2003
269
Apêndice 6
Versão:
1.0
Data: 10/10/2003
Estabilidade :
Dificuldade :
Atribuido a :
Comentário :
Release Alvo :
Rastrea de:
FEAT4.1 :Suporte ao Processo de Relato de Desempenho de Projetos
Rastrea para:
UC40 Registro de dados referentes à análise de tendências, variações e valor obtido dos
projetos de componentes
Texto do Requisito:Rd1.2 – É necessário um serviço que automaticamente, ou não, envie dados referentes a
análises de tendência, variação e valor obtido das Empresas Parceiras para a Empresa Líder do Projeto.
Atributos
Prioridade : Baixa
Status : Aprovado
Esforço :
Risco :
Estabilidade :
Dificuldade :
Atribuido a :
Comentário :
Release Alvo :
Rastrea de:
Rastrea para:
UC41 Registro de requisições de Mudança, mediante a análise de desempenho do Projeto.
Texto do Requisito:Rd1.3 – É necessário um serviço que permita o registro de requisições de mudanças,
vindas tanto da Proprietária do Projeto quanto da Parceiras, mediante a análise de desempenho do projeto.
Atributos
Prioridade : Alta
Computação
Aeronáutica, 2003
270
Apêndice 6
Versão:
1.0
Data: 10/10/2003
Status : Aprovado
Esforço :
Risco :
Estabilidade :
Dificuldade :
Atribuido a :
Comentário :
Release Alvo :
Rastrea de:
Rastrea para:
UC42 Atualizações no Plano do Projeto
Texto do Requisito:Rd2.1 – É necessário um serviço que possibilite atualizações no Plano do Projeto, tanto
por parte da Empresa Líder quanto por parte das Empresas Parceiras, porém, de forma coordenada.
Atributos
Prioridade : Alta
Status : Aprovado
Esforço :
Risco :
Estabilidade :
Dificuldade :
Atribuido a :
Comentário :
Release Alvo :
Rastrea de:
FEAT4.2 :Suporte ao Processo de Controle Integrado de Mudanças em Projetos
Rastrea para:
UC43 Registro de aceitação do escopo dos componentes
Computação
Aeronáutica, 2003
271
Apêndice 6
Versão:
1.0
Data: 10/10/2003
Texto do Requisito:Rd3.1 - É necessário um serviço que possibilite o registro de aceitação do escopo do
Projeto de Larga Escala, por parte das Empresas Parceiras, mediante informação de senha pertencente apenas
aos coordenadores de projetos das Parceiras envolvidas.
Atributos
Prioridade : Baixa
Status : Aprovado
Esforço :
Risco :
Estabilidade :
Dificuldade :
Atribuido a :
Comentário :
Release Alvo :
Rastrea de:
FEAT4.3 :Suporte ao Processo de Verificação do Escopo de Projetos
Rastrea para:
UC44 Registro das Informações que comporão relatórios de desempenho
Texto do Requisito:Rd4.1 – É necessário um serviço que permita às Empresas Parceiras registrarem
informações que comporão relatórios de desempenho;
Atributos
Prioridade : Alta
Status : Aprovado
Esforço :
Risco :
Estabilidade :
Dificuldade :
Atribuido a :
Comentário :
Release Alvo :
Rastrea de:
FEAT4.4 :Suporte ao Processo de Controle de Mudanças do Escopo de Projetos
Computação
Aeronáutica, 2003
272
Apêndice 6
Versão:
1.0
Data: 10/10/2003
Rastrea para:
UC45 Registro de requisições de mudança no Escopo do Projeto
Texto do Requisito:Rd4.2 – É necessário um serviço que possibilite à Empresa Líder do Projeto registrar
requisições de mudanças no escopo.
Atributos
Prioridade : Alta
Status : Aprovado
Esforço :
Risco :
Estabilidade :
Dificuldade :
Atribuido a :
Comentário :
Release Alvo :
Rastrea de:
Rastrea para:
UC46 Comunicação de mudanças sugeridas, em aprovação e aprovadas, em relação escopo
do projeto
Texto do Requisito:Rd4.3 – É necessário um serviço que possibilite a comunicação às Empresas Parceiras
do Projeto, sobre mudanças sugeridas, em aprovação e aprovadas em relação ao escopo do projeto.
Atributos
Prioridade : Alta
Status : Aprovado
Esforço :
Risco :
Estabilidade :
Dificuldade :
Atribuido a :
Computação
Aeronáutica, 2003
273
Apêndice 6
Versão:
1.0
Data: 10/10/2003
Comentário :
Release Alvo :
Rastrea de:
Rastrea para:
UC47 Comunicação à Proprietária do Projeto de atualizações no cronograma do projeto de
componentes
Texto do Requisito:Rd5.1 – É necessário um serviço que possibilite à Empresa Líder do Projeto tomar
conhecimento de atualizações no cronograma, feitas pelas Empresas Parceiras do Projeto.
Atributos
Prioridade : Alta
Status : Aprovado
Esforço :
Risco :
Estabilidade :
Dificuldade :
Atribuido a :
Comentário :
Release Alvo :
Rastrea de:
FEAT4.5 :Suporte ao Processo de Controle do Cronograma de Projetos
Rastrea para:
UC48 Comunicação às Empresas Parceiras de atualizações feitas no cronograma do projeto
Texto do Requisito:Rd5.2 – É necessário um serviço que possibilite às Empresas Parceiras tomarem
conhecimento de atualizações feitas no cronograma, pela Empresa Líder do Projeto.
Atributos
Prioridade : Alta
Status : Aprovado
Esforço :
Risco :
Estabilidade :
Computação
Aeronáutica, 2003
274
Apêndice 6
Versão:
1.0
Data: 10/10/2003
Dificuldade :
Atribuido a :
Comentário :
Release Alvo :
Rastrea de:
Rastrea para:
UC49 Relato do Desempenho do Projeto de Componentes à Proprietária do Projeto
Texto do Requisito:Rd6.1 – É necessário um serviço que possibilite às Empresas Parceiras informarem à
Empresa Líder do Projeto valores referentes aos totais das variáveis da Análise de Valor Obtido dos projetos
dos componentes que elas estão desenvolvendo, para que a Proprietária possa acompanhar o desempenho do
Atributos
Prioridade : Alta
Status : Aprovado
Esforço :
Risco :
Estabilidade :
Dificuldade :
Atribuido a :
Comentário :
Release Alvo :
Rastrea de:
FEAT4.6 :Suporte ao Processo de Controle de Custos de Projetos
Rastrea para:
UC50 Obtenção, por parte das Empresas Parceiras do Projeto, de informações sobre a Análise
de Valor Obtido do Projeto de Larga Escala
Texto do Requisito:Rd6.2 – É necessário um serviço que possibilite às Empresas Parceiras do Projeto
obterem informações sobre a Análise de Valor Obtido do Projeto de Larga Escala como um todo.
Atributos
Prioridade : Alta
Computação
Aeronáutica, 2003
275
Apêndice 6
Versão:
1.0
Data: 10/10/2003
Status : Aprovado
Esforço :
Risco :
Estabilidade :
Atribuido a :
Comentário :
Release Alvo :
Rastrea de:
Rastrea para:
UC51 Obtenção de informações referentes a Padrões de Qualidade estabelecidos pela
Proprietária do Projeto
Texto do Requisito:Rd7.1 – É necessário um serviço que possibilite às Empresas Parceiras obterem
informações referentes aos Padrões de Qualidade estabelecidos pela Empresa Líder do Projeto, para o produto
como um todo.
Atributos
Prioridade : Média
Status : Aprovado
Esforço :
Risco :
Estabilidade :
Dificuldade :
Atribuido a :
Comentário :
Release Alvo :
Rastrea de:
FEAT4.7 :Suporte ao Processo de Controle da Qualidade em Projetos
Rastrea para:
Computação
Aeronáutica, 2003
276
Apêndice 6
Versão:
1.0
Data: 10/10/2003
UC52 Obtenção de valores referentes ao controle e monitoramento de riscos do projeto de um
componente
Texto do Requisito:Rd8.1 – É necessário um serviço que informe à Empresa Líder do Projeto, valores
referentes a variáveis de controle e monitoramento de riscos referentes à execução dos projetos de componentes
delegados a empresas parceiras
Atributos
Prioridade : Alta
Status : Aprovado
Esforço :
Risco :
Estabilidade :
Dificuldade :
Atribuido a :
Comentário :
Release Alvo :
Rastrea de:
FEAT4.8 :Suporte ao Processo de Controle e Monitoração de Riscos em Projetos
Rastrea para:
UC53 Registro de encerramento de contrato entre Proprietária e Parceira do Projeto
Texto do Requisito:Re1.1 – É necessário um serviço que registre o encerramento do contrato entre a
Empresa Líder e a Parceira para um determinado componente do projeto. Dessa forma, a Empresa Líder passa a
não receber mais informações referentes ao elemento da WBS de seu projeto que se relaciona ao projeto do
componente desenvolvido pela Empresa Parceira.
Atributos
Prioridade : Média
Status : Aprovado
Esforço :
Risco :
Estabilidade :
Dificuldade :
Atribuido a :
Comentário :
Computação
Aeronáutica, 2003
277
Apêndice 6
Versão:
1.0
Data: 10/10/2003
Release Alvo :
Rastrea de:
FEAT5.1 :Suporte ao Processo de Encerramento de Contratos
Rastrea para:
UC54 Registro automático do percentual de completude de um elemento da WBS do Projeto
Texto do Requisito:Re2.1 – É necessário um serviço que permita marcar o percentual de completude de um
determinado elemento na WBS do Projeto, na Empresa Líder, mediante o registro do encerramento
administrativo, por parte das Empresas Parceiras, para o término de uma fase ou conclusão de um componente
que lhe foi delegado.
Atributos
Prioridade : Média
Status : Aprovado
Esforço :
Risco :
Estabilidade :
Dificuldade :
Atribuido a :
Comentário :
Release Alvo :
Rastrea de:
FEAT5.2 :Suporte ao Processo de Encerramento Administrativo de Projetos
Rastrea para:
STRQ1 Suporte às 9 (nove) Áreas de Conhecimento da Gestão de Projetos
Tipo de Requisito:Solicitação de Stakeholders
Texto do Requisito:É necessário que se provenha interoperabilidade quanto a execução dos processos
relacionados às 9 (nove) Áreas de Conhecimento da Gestão de Projetos, definidas pelo PMI
Atributos
Status : Aprovado
Comentário :
Rastrea de:
Rastrea para:
FEAT1 :Suporte aos Processos de Iniciação
FEAT2 :Suporte aos Processos de Planejamento
FEAT3 :Suporte aos Processos de Execução
Computação
Aeronáutica, 2003
278
Apêndice 6
Versão:
1.0
Data: 10/10/2003
FEAT4 :Suporte aos Processos de Controle
FEAT5 :Suporte aos Processos de Encerramento
STRQ1.1 Suporte à área de Gestão da Integração
Texto do Requisito:Gestão da Integração
Atributos
Status : Aprovado
Comentário :
Rastrea de:
Rastrea para:
FEAT4.2 :Suporte ao Processo de Controle Integrado de Mudanças em Projetos
STRQ1.2 Suporte à área de Gestão do Escopo
Texto do Requisito:Gestão do Escopo
Atributos
Status : Aprovado
Comentário :
Rastrea de:
Rastrea para:
FEAT2.2 :Suporte ao Processo de Detalhamento do Escopo
FEAT4.3 :Suporte ao Processo de Verificação do Escopo de Projetos
STRQ1.3 Suporte à Gestão de Prazos
Texto do Requisito:Gestão de Prazos
Atributos
Status : Aprovado
Comentário :
Rastrea de:
Rastrea para:
FEAT2.3 :Suporte ao Processo de Definição das Atividades
Computação
Aeronáutica, 2003
279
Apêndice 6
Versão:
1.0
Data: 10/10/2003
FEAT2.4 :Suporte ao Processo de Sequenciamento de Atividades
FEAT2.5 :Suporte ao Processo de Estimativa de Duração das Atividades
FEAT2.6 :Suporte ao Processo de Desenvolvimento do Cronograma
STRQ1.4 Suporte à área de Gestão de Custos
Texto do Requisito:Gestão de Custos
Atributos
Status : Aprovado
Comentário :
Rastrea de:
Rastrea para:
FEAT2.8 :Suporte ao Processo de Planejamento de Recursos
FEAT2.10 :Suporte ao Processo de Orçamentação de Custos
STRQ1.5 Suporte à área de Gestão da Qualidade
Texto do Requisito:Gestão de Qualidade
Atributos
Status : Aprovado
Comentário :
Rastrea de:
Rastrea para:
FEAT3.2 :Suporte ao Processo de Garantia da Qualidade
FEAT4.7 :Suporte ao Processo de Controle da Qualidade em Projetos
STRQ1.6 Suporte à área de Recursos Humanos
Texto do Requisito:Gestão de Recursos Humanos
Atributos
Status : Aprovado
Comentário :
Rastrea de:
Computação
Aeronáutica, 2003
280
Apêndice 6
Versão:
1.0
Data: 10/10/2003
Rastrea para:
FEAT2.13 :Suporte ao Processo de Planejamento Organizacional
FEAT2.14 :Suporte ao Processo de Montagem da Equipe
FEAT3.3 :Suporte ao Processo de Desenvolvimento da Equipe de Projeto
STRQ1.7 Suporte à área de Gestão da Comunicação
Texto do Requisito:Gestão da Comunicação
Atributos
Status : Aprovado
Comentário :
Rastrea de:
Rastrea para:
FEAT3.4 :Suporte ao Processo de dsitribuição das Informações
FEAT5.2 :Suporte ao Processo de Encerramento Administrativo de Projetos
STRQ1.8 Suporte à área de Gestão de Riscos
Texto do Requisito:Gestão de Riscos
Atributos
Status : Aprovado
Comentário :
Rastrea de:
Rastrea para:
FEAT2.7 :Suporte ao processo de Planejamento da Gestão de Riscos em Projetos
FEAT2.19 :Suporte ao Processo de Planejamento de Resposta a Riscos
FEAT4.8 :Suporte ao Processo de Controle e Monitoração de Riscos em Projetos
STRQ1.9 Suporte à área de Gestão de Aquisições
Texto do Requisito:Gestão de Aquisições
Atributos
Status : Aprovado
Computação
Aeronáutica, 2003
281
Apêndice 6
Versão:
1.0
Data: 10/10/2003
Comentário :
Rastrea de:
Rastrea para:
FEAT2.20 :Suporte ao Processo de Planejamento de Aquisições em Projetos
FEAT2.21 :Suporte ao Processo de Preparação de Aquisições em Projetos
FEAT3.5 :Suporte ao Processo de Pedido de Propostas
FEAT3.6 :Suporte ao Processo de Seleção de Fornecedores
FEAT3.7 :Suporte ao Processo de Administração de Contratos
FEAT5.1 :Suporte ao Processo de Encerramento de Contratos
STRQ2 Prover interoperabilidade na execução dos Processos da Gestão de Projetos
Texto do Requisito:É necessário que se provenha interoperabilidade na execução dos processos contantes
nos 5 (cinco) Grupos de Processos da Gestão de Projetos, definidos pelo PMI
Atributos
Status : Aprovado
Comentário :
Rastrea de:
Rastrea para:
STRQ2.1 Suporte ao Grupo de Processos de Iniciação
Texto do Requisito:Processos de Iniciação
Atributos
Status : Aprovado
Comentário :
Rastrea de:
Rastrea para:
FEAT1 :Suporte aos Processos de Iniciação
STRQ2.2 Suporte ao Grupo de Processos de Planejamento.
Texto do Requisito:Processos de Planejamento
Atributos
Status : Aprovado
Comentário :
Rastrea de:
Rastrea para:
FEAT2 :Suporte aos Processos de Planejamento
Computação
Aeronáutica, 2003
282
Apêndice 6
Versão:
1.0
Data: 10/10/2003
STRQ2.3 Suporte ao Grupo de Processos de Execução
Texto do Requisito:Processos de Execução
Atributos
Status : Aprovado
Comentário :
Rastrea de:
Rastrea para:
FEAT3 :Suporte aos Processos de Execução
STRQ2.4 Suporte ao Grupo de Processos de Controle
Texto do Requisito:Processos de Controle
Atributos
Status : Aprovado
Comentário :
Rastrea de:
Rastrea para:
FEAT4 :Suporte aos Processos de Controle
STRQ2.5 Suporte ao Grupo de Processos de Encerramento
Texto do Requisito:Processos de Encerramento
Atributos
Status : Aprovado
Comentário :
Rastrea de:
Rastrea para:
FEAT5 :Suporte aos Processos de Encerramento
STRQ3 Facilidades na utilização
Texto do Requisito:Os Serviços Web aplicáveis à Gestão de Projetos devem primar pela facilidade de sua
utilização.
Atributos
Status : Aprovado
Comentário :
Rastrea de:
Rastrea para:
FEAT6 :Permitir a customização de endereços e outros dados de identificação dos serviços
FEAT8 :Independência de Plataforma
Computação
Aeronáutica, 2003
283
Apêndice 6
Versão:
1.0
Data: 10/10/2003
FEAT9 :Acessibilidade via rede
FEAT11 :Facilidades para o Estabelecimento de Parcerias de Projetos
STRQ4 Confiabilidade
Texto do Requisito:Os Serviços Web aplicáveis à Gestão de Projetos devem ser confiáveis quando da
realização do processamento de informações distribuídas.
Atributos
Status : Aprovado
Comentário :
Rastrea de:
Rastrea para:
FEAT12 :Confiabilidade e Segurança no Processamento
STRQ5 Alta disponibilidade
Texto do Requisito:Os Serviços Web aplicáveis à Gestão de Projetos devem sempre estar disponíveis para
acesso, independente de dia e horário.
Atributos
Status : Aprovado
Comentário :
Rastrea de:
Rastrea para:
FEAT7 :Alta Disponibilidade
STRQ6 Conformidade com Padrões
Texto do Requisito:Os Serviços Web aplicáveis à Gestão de Projetos devem ser desenvolvidos com base em
padrões reconhecidos pela comunidade de desenvolvedores de software.
Atributos
Status : Aprovado
Comentário :
Rastrea de:
Rastrea para:
FEAT10 :Conformidade com Padrões
SS1 Log de Erros
Tipo de Requisito:Especificação Suplementar
Texto do Requisito:Quando ocorrerem falhas em transações e processamentos devem ser registrados logs de
erros tanto nos provedores quanto nos consumidores de WS4PM.
Atributos
Prioridade : Media
284
Computação
Aeronáutica, 2003
Apêndice 6
Versão:
1.0
Data: 10/10/2003
Status : Aprovado
Dificuldade : Media
Estabilidade : Media
Atribuído a :
Comentário :
Esforço :
Risco : Baixo
Release Alvo :
Rastrea de:
Rastrea para:
SS2 Parametrização de informações de acesso aos WS4PM
Texto do Requisito:Na implementação de aplicações consumidoras dos WS4PM deve-se propiciar aos
usuários a possibilidade de parametrizarem informações que customizem endereços de acesso, nomes dos
serviços e outros dados sensíveis à escolha de parceiros de projetos.
Atributos
Prioridade : Media
Status : Aprovado
Dificuldade : Media
Atribuído a :
Comentário :
Esforço :
Risco : Baixo
Release Alvo :
Rastrea de:
FEAT6 :Permitir a customização de endereços e outros dados de identificação dos serviços
Rastrea para:
SS3 Registro do Negócio e Serviços da Empresa em Servidores de Serviços UDDI
Texto do Requisito:Os usuários de WS4PM devem registrar informações sobre o seu negócio e os WS4PM
disponíveis, facilitando a integração com parceiros.
Computação
Aeronáutica, 2003
285
Apêndice 6
Versão:
1.0
Data: 10/10/2003
Atributos
Prioridade : Media
Status : Aprovado
Dificuldade : Media
Atribuído a :
Comentário :
Esforço :
Risco : Médio
Release Alvo :
Rastrea de:
Rastrea para:
SS4 Descrição de Web Services em WSDL
Texto do Requisito:Uma descrição do Serviço Web implementado deve ser provida em documentos WSDL,
propiciando facilidades na implementação de consumidores.
Atributos
Prioridade : Media
Status : Aprovado
Dificuldade : Media
Atribuído a :
Comentário :
Esforço :
Risco : Médio
Release Alvo :
Rastrea de:
Rastrea para:
SS5 Conexão a uma rede (Internet ou Intranet)
Computação
Aeronáutica, 2003
286
Apêndice 6
Versão:
1.0
Data: 10/10/2003
Texto do Requisito:É indispensável que as estações que acessarão os WS4PM estejam conectadas à rede
mundial de computadores (Internet) ou a uma rede privada, a uma velocidade média de 128Kbps
Atributos
Prioridade : Media
Status : Aprovado
Dificuldade : Media
Atribuído a :
Comentário :
Esforço :
Risco : Baixo
Release Alvo :
Rastrea de:
Rastrea para:
SS6 Interação mínina dos usuários
Texto do Requisito:Quando da implementação dos WS4PM em Softwares de Gestão de Projetos, deve-se
primar para que a aplicação comsumidora exija o mínimo de interação dos usuários, utilizando-se recursos
como gatilhos em eventos disparados quando da utilização das funcionalidades desses softwares.
Atributos
Prioridade : Media
Status : Aprovado
Dificuldade : Media
Atribuído a :
Comentário :
Esforço :
Risco : Médio
Release Alvo :
Rastrea de:
Rastrea para:
Computação
Aeronáutica, 2003
287
Apêndice 6
Versão:
1.0
Data: 10/10/2003
SS7 Transposição de Firewalls
Texto do Requisito:Os sistemas de proteção contra invasões do tipo firewalls não devem impedir que
consumidores acessem as funcionalidades expostas pelos WS4PM.
Atributos
Prioridade : Media
Status : Aprovado
Dificuldade : Media
Atribuído a :
Comentário :
Esforço :
Risco : Baixo
Release Alvo :
Rastrea de:
Rastrea para:
SS8 Disponibilidade 24x7
Texto do Requisito:Os Serviços Web Aplicáveis à Gestão de Projetos devem estar disponíveis para consumo
24 horas por dia e 7 dias por semana (24x7).
Atributos
Prioridade : Media
Status : Aprovado
Dificuldade : Media
Atribuído a :
Comentário :
Esforço :
Risco : Médio
Release Alvo :
Rastrea de:
FEAT7 :Alta Disponibilidade
Rastrea para:
Computação
Aeronáutica, 2003
288
Apêndice 6
Versão:
1.0
Data: 10/10/2003
SS9 Controle de Transações
Texto do Requisito:Devem ser implementados mecanismos para o controle de transações que envolvem
parceiros, incluindo a capacidade de se desfazer uma transação incompleta (Rollback).
Atributos
Prioridade : Media
Status : Aprovado
Dificuldade : Media
Atribuído a :
Comentário :
Esforço :
Risco : Alto
Release Alvo :
Rastrea de:
Rastrea para:
SS10 Tempo de Resposta
Texto do Requisito:Deve-se primar para que cada transação, exceto aquelas que envolvam o tráfego de
elementos atachados, como desenhos por exemplo, durem no máximo 10 segundos.
Atributos
Prioridade : Media
Status : Aprovado
Dificuldade : Media
Atribuído a :
Comentário :
Esforço :
Risco : Alto
Release Alvo :
Rastrea de:
Rastrea para:
Computação
Aeronáutica, 2003
289
Apêndice 6
Versão:
1.0
Data: 10/10/2003
SS11 Acessos Simultâneos
Texto do Requisito:Os WS4PM devem ser escaláveis, suportando acessos “simultâneos” de consumidores,
na faixa de 1 a 3000.
Atributos
Prioridade : Media
Status : Aprovado
Dificuldade : Media
Atribuído a :
Comentário :
Esforço :
Risco : Médio
Release Alvo :
Rastrea de:
Rastrea para:
SS12 Independência de interface na porção Consumidora
Texto do Requisito:Os WS4PM devem ser desenvolvidos de forma a não impor restrições à implementação
de interfaces de usuário no desenvolvimento de aplicações consumidoras, ou seja, qualquer tipo de
implementação, seja ela baseada em tecnologias da Web (acessíveis através de navegadores) ou não, devem ser
capazes de acionar e obter resultados dos WS4PM.
Atributos
Prioridade : Media
Status : Aprovado
Dificuldade : Media
Atribuído a :
Comentário :
Esforço :
Risco : Alto
Release Alvo :
Rastrea de:
Computação
Aeronáutica, 2003
290
Apêndice 6
Versão:
1.0
Data: 10/10/2003
Rastrea para:
SS13 Independência da plataforma de desenvolvimento da aplicação consumidora
Texto do Requisito:Deve-se permitir que qualquer aplicação cliente, independente da plataforma sobre a
qual foi desenvolvida, acesse os métodos implementados nos WS4PM.
Atributos
Prioridade : Media
Status : Aprovado
Dificuldade : Media
Atribuído a :
Comentário :
Esforço :
Risco : Médio
Release Alvo :
Rastrea de:
FEAT8 :Independência de Plataforma
Rastrea para:
SS14 Utilização da XML
Texto do Requisito:Os WS4PM devem utilizar a XML para a definição, transmissão, validação e
interpretação de dados entre aplicações.
Atributos
Prioridade : Media
Status : Aprovado
Dificuldade : Media
Atribuído a :
Comentário :
Esforço :
Risco : Baixo
Release Alvo :
Computação
Aeronáutica, 2003
291
Apêndice 6
Versão:
1.0
Data: 10/10/2003
Rastrea de:
Rastrea para:
SS15 Arquitetura em Camadas
Texto do Requisito:Quando da implementação de aplicações que terão funcionalidades expostas com base
nos WS4PM, deve-se primar pelo seu desenvolvimento baseado em estilos de Arquitetura em Camadas.
Atributos
Prioridade : Media
Status : Aprovado
Dificuldade : Media
Atribuído a :
Comentário :
Esforço :
Risco : Médio
Release Alvo :
Rastrea de:
Rastrea para:
SS16 Políticas de Autorização
Texto do Requisito:Os WS4PM devem ser implementados primando-se pela utilização de Políticas de
Autorização que impeçam que pessoas não autorizadas acessem ou alterem informações que não lhe dizem
respeito.
Atributos
Prioridade : Media
Status : Aprovado
Dificuldade : Media
Atribuído a :
Comentário :
Esforço :
Risco : Alto
Computação
Aeronáutica, 2003
292
Apêndice 6
Versão:
1.0
Data: 10/10/2003
Release Alvo :
Rastrea de:
Rastrea para:
SS17 Autenticação e Segurança Digital
Texto do Requisito:Para os WS4PM que exigirem segurança de informação, devem ser implementados
mecanismos de autenticação e segurança baseados em tecnologias de certificados e assinaturas digitais, como
por exemplo: certificados X.509 e bilhetes Kerberos.
Atributos
Prioridade : Media
Status : Aprovado
Dificuldade : Alta
Atribuído a :
Comentário :
Esforço :
Risco : Alto
Release Alvo :
Rastrea de:
Rastrea para:
SS18 Padrões propostos pela W3C (World Wide Web Consortium).
Texto do Requisito:Quando da implementação dos WS4PM sugere-se a observação dos padrões para
Serviços Web propostos pela W3C que podem ser acessados a partir de www.w3.org.
Atributos
Prioridade : Media
Status : Aprovado
Dificuldade : Media
Atribuído a :
Comentário :
Esforço :
Computação
Aeronáutica, 2003
293
Apêndice 6
Versão:
1.0
Data: 10/10/2003
Risco : Médio
Release Alvo :
Rastrea de:
Rastrea para:
SS19 Padrões propostos pela WS-I (Web Services Interoperability).
Texto do Requisito:Quando da implementação dos WS4PM sugere-se a observação dos padrões para
Serviços Web propostos pela WS-I que podem ser acessados a partir de www.ws-i.org.
Atributos
Prioridade : Media
Status : Aprovado
Dificuldade : Media
Atribuído a :
Comentário :
Esforço :
Risco : Médio
Release Alvo :
Rastrea de:
Rastrea para:
SS20 Definição de um Portal para possibilitar a utilização de alguns Serviços Web
Texto do Requisito:Rb15.2 – É necessário definir um Portal de Comunicação que permita a interação entre a
Proprietária e as Parceiras do Projeto onde alguns serviços propostos nesse documento pudessem ser acessados,
estendendo a implementação de eventuais portais atualmente utilizados por Empresas Proprietárias de Projeto.
Atributos
Prioridade : Media
Status : Aprovado
Dificuldade : Media
Atribuído a :
Comentário :
Computação
Aeronáutica, 2003
294
Apêndice 6
Versão:
1.0
Data: 10/10/2003
Esforço :
Risco : Médio
Release Alvo :
Rastrea de:
Rastrea para:
Computação
Aeronáutica, 2003
295
FOLHA DE REGISTRO DO DOCUMENTO
1.
CLASSIFICAÇÃO/TIPO
TM
5.
2.
DATA
3.
DOCUMENTO N°
4.
N° DE PÁGINAS
02 de março de 2004 CTA/ITA-IEC/TM-010/2004
295
TÍTULO E SUBTÍTULO:
Um Modelo de Interoperabilidade para Softwares de Gestão de Projetos
6.
AUTOR(ES):
7.
INSTITUIÇÃO(ÕES)/ÓRGÃO(S) INTERNO(S)/DIVISÃO(ÕES):
Instituto Tecnológico de Aeronáutica / Divisão de Ciência da Computação – ITA/IEC
8.
PALAVRAS-CHAVE SUGERIDAS PELO AUTOR:
Interoperabilidade de Software, Serviços Web, Gestão de Projetos em Parceria, Projetos de Larga Escala
9.PALAVRAS-CHAVE RESULTANTES DE INDEXAÇÃO:
Desenvolvimento de software; Gerenciamento de projetos; Administração de produção; Redes de comunicação;
Internet; Relações de cooperação; Empresas; Computação; Administração.
10.
APRESENTAÇÃO:
X Nacional
Internacional
Instituto Tecnológico de Aeronáutica, ITA. São José dos Campos, 2003, 295 páginas
11.
RESUMO:
Está se tornando comum que o desenvolvimento de produtos ou serviços seja realizado
conjuntamente por empresas parceiras ou contratadas, que podem estar situadas em diferentes partes do mundo.
Em geral, para entregar o produto ou serviço especificado dentro do prazo e com o custo planejado, a disciplina
de gerência de projetos tem sido empregada.
Esta disciplina consiste de grupos de processos para o inicio, planejamento, controle, execução e o
encerramento de atividades. Geralmente as empresas utilizam ferramentas computacionais para a realização do
trabalho de gerenciamento e é comum encontrar parceiras de projeto e contratadas utilizando ferramentas
distintas que possuem pouco ou nenhum recurso de integração. Isto resulta em dificuldades na gestão integrada
do projeto e de seus subprojetos, contribuindo para um controle ineficiente, altos custos e descumprimento de
prazos.
Este trabalho endereça os aspectos de interoperabilidade entre softwares de gestão de projetos,
envolvendo um levantamento dos requisitos de comunicação e integração, com base na metodologia de gestão
proposta pelo PMBOK, para propor um modelo de solução em que estes softwares exponham funcionalidades
que possam ser invocadas remotamente, para a realização de processamentos e troca de dados entre empresas
parceiras de projeto.
A tecnologia de serviços Web foi investigada como alternativa para a implementação da solução
proposta devido ao fato de ser baseada em padrões abertos e tecnologias WWW disponíveis.
A especificação de requisitos foi realizada com base nos conceitos do PMBOK e em entrevistas
com a equipe de gerenciamento de projetos do Programa EMBRAER 170/190. Estes projetos são desenvolvidos
em parceria com várias empresas, e cada uma delas é responsável pelo desenvolvimento de uma ou mais partes,
que compõem os produtos desses projetos.
O modelo de solução e a tecnologia de serviços Web foram testados e validados por meio da
implementação de dois protótipos de software de gestão de projetos, concebidos a partir das tecnologias Java e
.NET. Eles representam softwares de gestão de projetos de fabricantes diferentes que trocam dados, propiciando
a aplicação da técnica Análise de Valor Agregado em projetos relacionados.
12.
GRAU DE SIGILO:
(X ) OSTENSIVO ( ) RESERVADO
( ) CONFIDENCIAL
( ) SECRETO