SISTEMA DE ENSINO PRESENCIAL CONECTADO

SUPERIOR DE TECNOLOGIA EM ANALISE E

DESENVOLVIMENTO DE SISTEMAS
RICARDO MERCADANTE DREWS

PORTFLIO INDIVIDUAL
4 Semestre

Londrina
2015

RICARDO MERCADANTE DREWS

PORTFLIO INDIVIDUAL
4 Semestre

Trabalho de Produo de Texto Individual apresentado

Universidade Norte do Paran - UNOPAR, como
requisito parcial para a obteno de mdia bimestral nas
disciplinas de Projeto Orientado a Objetos, Engenharia e
Projeto de Software e Programao para Web II
Orientador: Prof.

Sumrio
Londrina
2015

Marcio Roberto Chiaveli

Lus Claudio Perini
Marco Ikuro Hisatomi
Veronice de Freitas

Sumario
Sumario.........................................................................................................................3
Introduo......................................................................................................................5
Objetivos........................................................................................................................6
DESAFIO 1....................................................................................................................7
5 Gerenciamento do escopo do projeto............................................................................7
5.1 Planejamento do escopo............................................................................................7
5.2 Definio do escopo...................................................................................................8
5.3 Criar EAP................................................................................................................... 9
5.4 Verificao do escopo..............................................................................................10
5.5 Controle do escopo..................................................................................................10
11 - Gerenciamento de Riscos..........................................................................................12
11.1 Planejamento de gerenciamento de riscos.............................................................12
11.2 Identificao dos riscos..........................................................................................13
11.3 Anlise qualitativa de riscos...................................................................................14
11.5 Planejamento de resposta a riscos.........................................................................16
11.6 Monitoramento de riscos........................................................................................17
12 - Gerenciamento de aquisies do projeto...................................................................18
12.1 Planejar compras e aquisies............................................................................18
12.2 Planejar contrataes............................................................................................20
12.3 Solicitar respostas dos fornecedores.....................................................................20
12.4 Selecionar fornecedores........................................................................................21
12.5 Administrao de contrato......................................................................................22
12.6 Encerramento do contrato......................................................................................23

DESAFIO 02................................................................................................................24
11 Projeto de Arquitetura................................................................................................24
11.1 Decises de projeto de arquitetura.........................................................................24
11.2 Organizao de sistema.........................................................................................25
11.3 Estilos de decomposio modular..........................................................................26
11.4 Modelos de controle...............................................................................................27
11.5 Arquiteturas de referncia......................................................................................29
12 - Arquiteturas de Sistemas Distribudos........................................................................30
12.1 Arquitetura de multiprocessadores.........................................................................31
12.2 Arquitetura cliente-servidor.....................................................................................31

12.3 Arquiteturas de objetos distribudos.......................................................................32

12.4 Computao interorganizacional distribuda..........................................................33
13 Arquitetura de aplicaes.............................................................................................36
13.1 Sistemas de processamento de dados..................................................................36
13.2 Sistema de processamento de transaes............................................................37
13.3 Sistemas de processamento de eventos................................................................38
13.4 Sistema de processamento de linguagens.............................................................38
29 Gerenciamento de configuraes.................................................................................39
29.1 Planejamento de gerenciamento de configuraes................................................39
29.2 Gerenciamento de mudanas................................................................................40
29.3 Gerenciamento de verses e releases...................................................................41
29.4 Construo de sistemas.........................................................................................42
29.5 Ferramentas CASE para gerenciamento de configuraes...................................42

DESAFIO 3..................................................................................................................44
Desafio 3.1........................................................................................................................ 44
Desafio 3.2........................................................................................................................ 45
Desafio 3.3........................................................................................................................ 46

DESAFIO 4..................................................................................................................47
Concluso....................................................................................................................49
REFERNCIAS BIBLIOGRAFICAS............................................................................50

Introduo
Neste trabalho abordaremos diversas reas de competncia necessrias para o
desenvolvimento de um projeto de software.
Num primeiro momento abordaremos tcnicas de gerenciamento de projeto para as
ares de escopo de projeto, anlise de riscos de projeto e escolha de fornecedores de acordo
com as normas PMBOK
Em seguida faremos um estudo sobre alguns tpicos de projeto de arquitetura de
softwares de acordo com o livro Engenharia de Software de Ian Sommerville 8 Edio.
Continuando com o nosso trabalho, faremos uma breve analise sobre alguns
frameworks Java para desenvolvimento web com um breve comparativo entre eles
Por fim, faremos um estudo hipottico sobre o estudo de casa da China Telecom,
analisando alguns aspectos do projeto China Telecom.

Objetivos
Este estudo visa obter conhecimento e adquirir novas competncias para o processo
de gerenciamento de projetos na rea de desenvolvimento de softwares. Com este estudo
visamos aperfeioar os processos de gerencia de projetos de escolha de fornecedores,
determinao de escopos de projeto e gerenciamento de riscos
Tambm buscamos desenvolver habilidade na rea de desenvolvimento de software
com estudos de frameworks e analises de modelos de projetos de softwares

DESAFIO 1
5 Gerenciamento do escopo do projeto
O planejamento do escopo do projeto trata de definir o que ser feito durante o
projeto de forma que garanta que todo o trabalho necessrio ser realizado sem que sejam
feitos trabalhos desnecessrios aos objetivos do projeto.

5.1 Planejamento do escopo

A definio e o gerenciamento do escopo do projeto influenciara no sucesso total do
projeto. O plano de gerenciamento do escopo e um ferramenta que descreve como a equipe
ir definir o escopo do projeto, desenvolver a declarao detalhada do projeto, definir e
desenvolver a estrutura analtica do projeto, verificar o escopo do projeto e controlar o
escopo do projeto.
Para o seu desenvolvimento o planejamento do escopo utiliza:

Fatores ambientais da empresa com cultura e infraestrutura.

Ativos de processos organizacionais como politicas organizacionais, procedimentos

organizacionais e informaes histricas de projetos anteriores.

Termo de abertura do projeto
Declarao do escopo preliminar do projeto
Plano de gerenciamento do projeto
Para seu desenvolvimento, o plano de gerenciamento de escopo utiliza as seguintes
ferramentas e tcnicas:

Opinio especializada sobre como projetos equivalentes realizaram o gerenciamento do

escopo
Modelos das estrutura analtica do projeto
Formulrios de controle de mudanas no escopo do projeto
Modelos de planos de gerenciamento do escopo
Normas
Com essas ferramentas geramos as seguintes contribuies no plano de gerenciamento do
projeto:

Plano de gerenciamento do escopo do projeto fornecendo orientao sobre como o escopo

o
o
o
o

do projeto ser definido, documentado, gerenciado e controlado. Esse plano deve incluir:
Processo de preparao de uma declarao detalhada do escopo
Processo de criao da EAP a partir da declarao do escopo
Especificao da obteno da aceitao e verificao do termino do projeto
Processo para controlar e processar solicitaes de mudanas da declarao detalhada do
escopo.

5.2 Definio do escopo

A declarao do escopo detalhada do projeto feita a partir das principais entregas,
premissas e restries documentadas durante a iniciao do projeto. As premissas e
restries so analisadas para garantir que atendam s necessidades, desejos e
expectativas das partes interessadas.
A definio do escopo utiliza os seguintes documentos como fonte de informao:

Ativos de processos organizacionais

Termo de abertura do projeto
Declarao do escopo preliminar do projeto
Plano de gerenciamento do escopo do projeto
Solicitaes de mudana aprovadas
A definio do escopo utiliza as seguintes ferramentas e tcnicas para o seu
desenvolvimento.

Analise de produtos
Identificao de alternativas
Opinio especializada
Analise das parte interessadas
A contribuio gerada ao projeto ser a declarao do escopo do projeto
descrevendo em detalhes as entregas do projeto e o trabalho necessrio para criar essas
entregas. O grau e o nvel de detalhe com que uma declarao do escopo do projeto define
o trabalho que ser realizado e o trabalho que ser excludo podem determinar a eficcia
com que a equipe de gerenciamento do projeto poder controlar o escopo global do projeto.
A declarao do escopo detalhada do projeto deve incluir?

Objetivos do projeto includo critrios mensurveis para o seu sucesso

Descrio do escopo do produto, servio ou resultado com suas caractersticas.
Requisitos do projeto descrendo as condies ou capacidades que devem ser atendidas ou

possudas pelas entregas do projeto para satisfazer um contrato

Limites do projeto identificando o que est includo.
Entregas do projeto, incluindo no apenas o produto ou servio final como suas sadas

auxiliares.
Critrios para aceitao de produtos
Restries do projeto como datas limites, oramentos clusulas contratuais.
Premissas do projeto
Organizao inicial do projeto com identificas dos membros da equipe e partes interessadas
Riscos iniciais definidos
Marcos do cronograma
Limitao de fundos
Estimativa de custos
Requisitos de gerenciamento de configurao do projeto
Especificaes do projeto

Requisitos de aprovao

5.3 Criar EAP

A EAP organiza e define o escopo total do projeto subdividindo o trabalho total em
partes menores mais facilmente gerenciveis. Funciona de forma hierarquizada e em cada
nvel descendente apresenta uma definio mais detalhada do trabalho do projeto. Os nveis
mais baixos so denominados pacotes de trabalho.
Para criao da EAP utilizaremos:

Os ativos de processos organizacionais

A declarao do escopo do projeto
O plano de gerenciamento do escopo do projeto
As solicitaes de mudanas aprovadas
As tcnicas e ferramentas para criao da EAP so:

Modelos da estrutura analtica do projeto.

Decomposio, subdividindo as entregas do projeto em componentes menores e mais

o
o
o

facilmente gerenciveis. A decomposio inclui as seguintes atividades

Identificao das entregas e do trabalho relacionado
Estruturao e organizao da EAP
Decomposio dos nveis mais altos da EAP em componentes detalhados de nvel mais

o
o

baixo
Desenvolvimento e atribuio de cdigos de identificao aos componentes EAP
Verificar se o grau de decomposio do trabalho necessrio e suficiente.
O resultado desse processos iro gerar a seguinte contribuio no gerenciamento do
projeto:

Atualizaes na declarao de escopo do projeto

Uma estrutura analtica do projeto
Dicionrio EAP
Linha base do escopo do projeto
Atualizaes no plano de gerenciamento do escopo do projeto

5.4 Verificao do escopo

A verificao do escopo trata da aprovao formal pelas partes interessadas e
formalizao desta aceitao.
Para isso utilizamos a declarao do escopo do projeto, o dicionrio da EAP o plano
de gerenciamento do escopo do projeto e as entregas e atravs de um processo de
inspeo utilizando tcnicas de medio, exame e verificao para determinar se o trabalho
e as entregas atendem aos requisitos e aos critrios de aceitao.

10
Como resultado da verificao do escopo teremos no plano de gerenciamento os
documentos de entregas aceitas, onde as entregas aceitas sero documentadas, bem com
as entregas no aceitas com as razes da no aceitao.

5.5 Controle do escopo

O controle de escopo trata de gerenciar e controlar as mudanas solicitadas e as
aes corretivas recomendas, garantindo que essas mudanas e correes sejam
processadas por meio de um processo de controle. Mudanas no controladas so
frequentemente chamadas de aumento do escopo de projeto.
O controle do escopo utiliza-se do seguintes documentos:

Declarao do escopo do projeto

Estrutura analtica do projeto
Dicionrio EAP
Plano de gerenciamento do escopo do projeto
Relatrios de desempenho
Solicitaes de mudana aprovadas
Informaes sobre o desempenho do trabalho
Com esses documentos, aplicamos as seguinte tcnicas e ferramentas:

Sistema de controle de mudanas para definir os procedimentos para efetuar mudanas no

escopo do projeto e no escopo do produto.

Analise de variao para avaliar a extenso da variao no projeto.
Replanejamento: mudanas aprovadas que afetem o escopo do projeto podem exigir
modificaes na EAP, na declarao do escopo do projeto e no plano de gerenciamento do

escopo do projeto.
Sistema de gerenciamento de configurao para garantir que mudanas solicitadas no
escopo do projeto e no escopo do produto sero cuidadosamente consideradas e
documentadas, antes de serem processadas pelo processo Controle integrado de
mudanas.
Assim, iremos obter os seguintes documentos no plano de gerenciamento de projeto:

Atualizaes da declarao do escopo do projeto

Atualizaes da estrutura analtica do projeto
Atualizaes do dicionrio da EAP
Atualizaes da linha de base do escopo
Mudanas solicitadas.
Aes corretivas recomendadas
Atualizaes nos ativos de processos organizacionais
Atualizaes no plano de gerenciamento do projeto.

11

12

11 - Gerenciamento de Riscos
O gerenciamento do riscos trata de identificar, monitorar, controlar e responder aos
riscos ao projeto. Por riscos entendemos que qualquer eventos ou condio incerta que se
ocorrer ira causar um impacto negativo ou positivo sobre pelo menos um objetivo do projeto.
Discutiremos a seguir os processos para gerenciamento dos riscos de um projeto

11.1 Planejamento de gerenciamento de riscos

Nesta fase deve ser decidido a forma como iremos abordar as atividades do
gerenciamento de riscos. Aqui sero decididos como iremos abordar e tratar os riscos do
projeto em todas as fases que se seguem. Esta fase deve ser concluda no incio do
planejamento do projeto para garantir sua execuo com sucesso em todas as demais
fases.
Para fazer o planejamento dos riscos devemos utilizar as entradas do projeto como
os fatores ambientais da empresa, a declarao do escopo do projeto e o plano de
gerenciamento do projeto e partindo dos dados destes realizar reunies de onde sairo os
planos bsicos para executar as atividades de riscos.
Sero criados modelos organizacionais gerais para categorias de riscos, analisados
os custos que de riscos para que possam ser includos no oramento, designadas
responsabilidade de riscos, etc. Dessas reunies teremos definidos pelos menos os
seguintes itens do plano de gerenciamento de riscos.

Metodologia: define as abordagens, ferramentas e fontes de dados para execuo do plano

de gerenciamento de risco
Funes e Responsabilidades: Define os responsveis por cada rea de gerenciamento e

suas funes.
Oramentao: Designa recursos e estima os custos necessrios para o gerenciamento de

riscos com o objetivo de inclu-los na linha de base dos do projeto

Tempos: Define a frequncia do processo de gerenciamento de riscos no projeto e como

suas atividades sero includas no cronograma.

Categorias de riscos: decide os mtodos para definio das categorias de riscos, os
mtodos para reviso dessas categorias e como elas sero criada e acompanhadas durante

o projeto.
Definio de probabilidade de Impactos de riscos: Define a anlise qualitativa dos riscos
definindo os mtodos e escalas para aplica-las

13

11.2 Identificao dos riscos

O processo de identificao dos riscos de ser feita de formas cclica j que os riscos
podem mudar. Os participantes dessas equipes podem ser membros da equipe de projeto,
gerentes de projeto, equipe de gerenciamento de riscos, especialistas e partes interessadas.
Analisando os fatores ambientais da empresa, os ativos de processos
organizacionais, plano de gerenciamento de riscos e o plano de gerenciamento de projeto
essa equipe aplicara ferramentas tcnicas como:

o
o
o
o
o

o
o
o

Reviso de documentao
Tcnicas de coleta de informao
Brainstorming
Tcnica Delphi
Entrevistas
Identificao da causa raiz
Analise dos pontos fortes e fracos, oportunidades e ameaas.
Analise da lista de verificao
Analise de premissas
Tcnicas com diagramas
Diagramas de causa e efeito
Diagramas do sistema ou fluxogramas
Diagramas de influncia
Com a aplicao de tcnicas para essas analises a equipe ir gerar os seguintes
registros de riscos para o projeto de gerenciamento de riscos.

Lista de riscos identificados: descreve os riscos identificados com suas causas e as

premissas incertas do projeto.

Lista de respostas possveis: As respostas possveis a um risco identificado.
Causa raiz do risco: condies ou eventos que podem produzir o risco identificado
Categoria de risco atualizadas: Caso tenham sido identificadas novas categorias de riscos a
lista anterior deve ser atualizada e aprimorada.

14

11.3 Anlise qualitativa de riscos

A anlise qualitativa define maneiras de priorizar as resposta aos riscos avaliando
sua prioridade atravs da probabilidade de ocorrerem, seu impacto nos objetivos do projeto
caso os riscos realmente ocorram, alm de outros fatores, como prazo e tolerncia a risco
das restries de custo, cronograma, escopo e qualidade do projeto.
uma maneira rpida e econmica de estabelecer prioridades pra o planejamento
de resposta a riscos que deve ser constantemente reexaminada durante o ciclo do projeto
para acompanhar as mudanas de riscos do projeto.
A estratgias para definio dos riscos qualitativamente inclui:

Avaliao da probabilidade e impacto de riscos: feita para cada um dos riscos identificados
e atravs de entrevistas e analises com membros da equipe e atribudo um nvel ao risco,

com detalhes sobre a explanao que justificam a atribuio recebida.

Matriz de probabilidade e impacto: essa matriz especifica as combinaes de probabilidade
e impacto que levam classificao dos riscos como de prioridade baixa, moderada ou alta.
Podem ser usados termos descritivos ou valores numricos, dependendo da preferncia

organizacional.
Avaliao qualidade dos dados sobre riscos: Uma anlise qualitativa de riscos exige dados
exatos e imparciais para ser confivel. A anlise da qualidade dos dados sobre riscos uma
tcnica para avaliar o grau de utilidade dos dados sobre riscos para o gerenciamento de
riscos. Ela envolve examinar at que ponto o risco entendido e tambm a exatido,

qualidade, confiabilidade e integridade dos dados sobre riscos

Categorizao dos riscos: dividir os riscos em categorias por fontes, rea de projeto

afetada, raiz dos risco, etc.

Avaliao da urgncia do risco: os riscos que requerem respostas a curto prazo podem ser
considerados mais urgentes.
A partir da anlise qualitativa o relatrio de gerenciamento de riscos ser atualizado
com os seguintes dados:

Classificao relativa ou a lista de prioridades dos riscos do projeto

Riscos agrupados por categoria
Lista de riscos que exigem resposta a curto prazo
Lista de riscos para anlise e resposta adicionais
Lista de observao de riscos de baixa prioridade
Tendncias de resultados da anlise qualitativa de riscos

15

11.4 Analise quantitativa de riscos

realizada nos riscos priorizados pelo processo de Anlise qualitativa de riscos por
afetarem as demandas conflitantes do projeto atribuindo a eles uma classificao numrica
com o objetivo de quantificar possveis resultados do projeto e suas probabilidades, avaliar a
probabilidade de atingir objetivos especficos do projeto, identificar os riscos que exigem
mais ateno quantificando sua contribuio relativa para o projeto, identificar metas
realistas e alcanveis de custo, cronograma ou escopo quando fornecidos os riscos do
projeto e determinar a melhor deciso de gerenciamento de projetos quando algumas
condies ou resultados forem incertos.
O processo bem parecido com o da anlise qualitativa, as estratgias principais
para determinar a anlise quantitativa so:

Distribuio de probabilidades: representando as incertezas com relao aos valores e

durao de atividades.
Opinio especializada: especialista no assunto, internos ou externos, validam os dados e as

o
o

tcnicas.
Anlise quantitativa de riscos e tcnicas de modelagem:
Anlise de sensibilidade: quais os riscos de maior impacto potencial para o projeto
Anlise de valor monetrio esperado: Valor monetrios esperado com base em conceitos

estatsticos sobre o que pode ou no acontecer.

Analise da arvore de deciso: descreve uma situao que est sendo considerada e as

possveis implicaes de cada escolha disponvel.

Modelagem e simulao: Uma simulao do projeto utiliza um modelo que traduz as
incertezas especificadas em um nvel detalhado do projeto para seu impacto potencial nos
objetivos do projeto
Essas estratgias iro gerar o seguinte resultado no processo de gerenciamento de
riscos:

Anlise probabilstica do projeto

Probabilidade de realizao do objetivos de custo e tempo
Lista priorizada de riscos quantificados
Tendncias dos resultados da anlise quantitativa de riscos

16

11.5 Planejamento de resposta a riscos

A resposta a riscos deve utilizar as anlises quantitativas e qualitativas para
determinar respostas as ameaas do projeto, levando em conta a importncia do risco,
reduzindo assim as ameaas ao projeto.
Existem vrias estratgias de resposta a riscos e elas devem ser escolhidas de
acordo com a probabilidade de ser eficaz contra o risco em questo.
Trs estratgias principais para riscos que podem ter impactos negativos so:

Prevenir: mudanas no plano de gerenciamento para eliminar ou isolar a ameaa.

Transferir: Ao invs de eliminar o risco ela transfere o risco e a responsabilidade de suas

consequncias para terceiros, como por exemplo, fazer um seguro.

Mitigar: Procura reduzir a probabilidade ou o impacto do risco a um nvel aceitvel.
Para riscos de impacto positivo tambm existem algumas estratgias bsicas para
utilizarmos:

Explorar: busca garantir que a oportunidade seja concretizada

Compartilhar: procura atribuir a oportunidade a terceiros que possam aproveita-la melhor em

benefcio do projeto.
Melhorar: procura aumentar a significncia da propriedade atravs do aumento da
probabilidade ou dos impactos positivos atravs da identificao e maximizao dos seu
acionadores.
Para algumas ameaas e oportunidades tambm podemos utilizar a estratgia de
aceitao, pois como raramente podemos eliminar todos os riscos do projeto, muitas vezes
e melhor simplesmente aceitar a ameaa ou oportunidade. A aceitao pode ser passiva,
onde no se toma nenhuma atitude, ou ativa, onde pode-se estabelecer reservas para o
caso do risco se concretizar.
Tambm podemos ter respostas contingenciadas, ou seja, resposta projetadas para
uso apenas se determinados eventos ocorrerem. Desta forma os marcos que ativam a
resposta contingenciada devem ser monitorados constantemente.
Aps a determinao das resposta de risco, atualizamos os registros de riscos com
as informaes definidas para cada risco, mantendo um relatrio mais detalhado para riscos
considerados moderados e altos, contendo o que foi definido sobre o gerenciamento de
cada um deles, e uma lista de observao a ser monitorada periodicamente para riscos
considerados de baixa prioridade.
Tambm so tomadas nesse ponto aes para fazer acordos contratuais como
seguros servios e outros itens conforme adequado, especificando a responsabilidade das
partes envolvidas por riscos especficos caso ocorram.

17

11.6 Monitoramento de riscos

O monitoramento de risco deve ser executado durante toda a vida do projeto com o
objetivo de monitorar os riscos listados, reanalisar riscos, monitorar condies de
acionamento dos planos de contingencia, se as premissas do projeto continuam validas, se
os procedimentos e polticas do gerenciamentos esto adequados e sendo seguidos, avaliar
as reservas de cronograma e custos, etc.
Para ser executado ele utiliza-se das seguintes ferramentas:

Reavaliao constante dos riscos existentes e identificao de novos riscos

Auditoria de riscos para avaliar as respostas aos risco identificados e a eficcia do processo

de gerenciamento de riscos
Anlise de tendncias e da variao e reviso utilizando os dados de desempenho gerados

pelo projeto.
Medio do desempenho tcnico comparando as realizaes tcnicas com o cronograma do

plano de gerenciamento do projeto.

Analise das reservas comparando-as com a quantidade restante de riscos em qualquer

momento do projeto avaliando se est adequada.

Reunies de andamento para praticar e discutir os riscos, aumentando assim a exatido do
entendimento dos riscos e ameaas
Essas ferramentas devero gerar os seguintes resultados no gerenciamento do
projeto:

Registros atualizados da reavaliaes de riscos, auditorias de riscos e das revises dos

riscos, bem como os resultados reais dos riscos do projetos e das respostas a riscos.
Registro das mudanas solicitadas geradas por planos de contingncia ou solues

alternativas.
Aes corretivas recomendadas
Aes preventivas recomendadas para assegurar a conformidade do projeto com o plano de

gerenciamento de projeto
Ativos de processos organizacionais atualizados para uso futuro
Atualizao do plano de gerenciamento com as mudanas aprovadas.

12 - Gerenciamento de aquisies do
projeto
O gerenciamento de aquisio do projeto e responsvel pelos processos para
comprar ou adquirir produtos, servios ou resultados necessrios de fora da equipe do

18
projeto. Tambm trata da administrao de qualquer contrato emitido por uma organizao
externa (comprador) que est adquirindo o projeto da organizao executora (o fornecedor)
e a administrao das obrigaes contratuais.
Neste capitulo consideramos que o comprador de itens para o projeto pertence a
equipe do projeto e que o fornecedor externo a equipe do projeto.

12.1Planejar compras e aquisies

Aqui devemos decidir o que, quanto e quando adquirir produtos ou servios,
considerando possveis fornecedores, Tambm devemos considerar licenas profissionais
relevantes que podem ser exigidas pela legislao, regulamento ou poltica organizacional
na execuo do projeto.
O planejamento de compras e aquisies deve levar em conta os seguintes fatores:

Fatores ambientais da empresa, como condies de mercado, produtos, servios e

resultados disponveis no mercado

Ativos de processos organizacionais que iro fornecer as polticas, procedimentos, diretrizes

e sistemas de gerenciamento formais e informais existentes na organizao.

Declarao do escopo do projeto descrevendo os limites, requisitos, restries e premissas

do projeto.
Estrutura analtica do projeto observando a relao entre todos os componentes do projeto e

as entregas do projeto.
Dicionrio EAP que fornecer declaraes do trabalho detalhadas para uma identificao
das entregas e um descrio do trabalho dentro de cada componente da EAP necessrio

para produzir a entrega

Plano de gerenciamento de projeto onde teremos o plano geral do projeto e planos
auxiliares, como o gerenciamento de riscos e cronograma do projeto, para planejamento de
gerenciamento de aquisies.

19
Para fazer o planejamento de compras e aquisies usaremos as seguintes tcnicas:

Anlise de fazer ou comprar: analisando os custos e capacidades disponveis determina se

melhor comprar, produzir ou alugar determinado produto ou servio. Aqui devemos levar

em conta alm dos custos para o projeto as estratgias de longo prazo da organizao
Opinio especializada: ajudara a avaliar critrios usados para avaliao das propostas e

ofertas feitas por fornecedores

Tipos de contratos: Dependendo os requisitos, verses, impostos e outras peculiaridades
juntamente com o grau de competio e risco do mercado precisam ser avaliados para
determinar qual o melhor tipo de contrato para cada aquisio.
A utilizao dessas ferramentas ir gerar os seguintes dados no plano de
gerenciamento do projeto:

Tipos de contrato a serem usados

Quem ir preparar estimativas independentes e se elas sero necessrias como critrio de

avaliao.
As aes que a equipe de gerenciamento ter autonomia para executar sozinha.
Documentos de aquisio padronizados (se necessrio)
Gerenciamento de vrios fornecedores
Coordenao de aquisies com outros aspectos do projeto
Tratamento de tempos necessrios para aquisio
Definio de datas para entrega de contratos.
Identificao dos seguros para mitigas alguns riscos do projeto.
Definio de orientaes que sero fornecidas aos fornecedores sobre o projeto.
Identificao de fornecedores pr-qualificados, se necessrio
Mtricas de aquisio a serem usadas para gerenciar contratos e avaliar fornecedores.
Declarao do trabalho do contrato desenvolvida a partir do escopo do projeto de forma

clara, completa e concisa, incluindo descrio dos servios e apoio necessrios.

Decises de fazer ou comprar documentadas de forma simples como, por exemplo, uma
lista que inclui uma justificativa curta para cada deciso

20

12.2 Planejar contrataes

O processo Planejar contrataes prepara os documentos necessrios para dar suporte ao
processo Solicitar respostas de fornecedores e ao processo Selecionar fornecedores.
As principais ferramentas utilizadas so:

Formulrios padro: estes podem incluir contratos padro, descries padro de itens de

aquisio, termos de confidencialidade, listas de verificao de critrios entre outros.

Opinio especializada
A utilizao das ferramentas acima ir gerar todos os documentos padronizados com
descries de itens e modelos de contratos que sero utilizados durante o projeto para
facilitar e garantir uma resposta exata dos fornecedores. A complexidade e o nvel de
detalhes dos documentos de aquisio deve ser proporcional ao valor da compra ou
aquisio planejada e com os riscos associados a ela.
Os critrios de avaliao desenvolvidos podero ir para o projeto de uma forma
simplificada, ficando limitados ao custo de aquisio ou utilizar outros critrios como, por
exemplo, o entendimento que o fornecedor teve da necessidade, capacidade tcnica,
capacidade financeira, abordagem tcnica, referencias, tamanho e tipo do negcio e direitos
de propriedade.

12.3 Solicitar respostas dos fornecedores

O processo de solicitar respostas de fornecedores obtm respostas, como cotaes
e propostas, de possveis fornecedores sobre como os requisitos do projeto podem ser alcanados.

Os possveis fornecedores, normalmente sem custos diretos para o projeto ou o comprador,

gastam a maior parte do esforo real nesse processo.
Para isso utilizamos dados dos ativos e processos organizacionais, plano de gerenciamento
de aquisies e documentos de aquisies aplicando as seguintes tcnicas e ferramentas:

Reunies com licitantes

Anncios
Desenvolvimento de uma lista de fornecedores qualificados
Essas tcnicas e ferramentas iro gerar os seguintes itens no projeto

Lista de fornecedores qualificados

Pacote de documentos de aquisio
Propostas de fornecedores

21

12.4 Selecionar fornecedores

Os fornecedores sero selecionados de acordo com os critrios necessrios a cada
tipo de produto ou servio. Em alguns casos a avaliao levara em conta apenas preos, em
outros o preo ser analisado juntamente com a avaliao de critrios tcnicos, com cada
um tendo um peso na avaliao.
Uma pequena lista de fornecedores qualificados pode ser estabelecida utilizando-se
propostas preliminares.
Utilizaremos para essa seleo dados dos ativos de processos organizacionais,
plano de gerenciamento de aquisies, critrios de avaliao, pacote de documentao,
propostas, lista de fornecedores qualificados e o prprio plano de gerenciamento do projetos
para avaliao dos riscos estabelecidos.
As principais tcnicas e ferramentas para a seleo de fornecedores so:

Sistema de ponderao:
Estimativas independentes
Sistemas de triagem
Negociao de contrato
Sistema de qualificao de fornecedores
Opinio especializada
Tcnicas de avaliao de propostas
Essas tcnicas iro gerar os seguintes itens para o processo de gerenciamento de
projeto

Fornecedores selecionados
Contratos assinados com fornecedores selecionados
Plano de gerenciamento de contratos para compras ou aquisies significativas
Disponibilidade de recursos
Atualizaes no plano de gerenciamento de aquisies
Solicitaes de mudanas no plano de gerenciamento de projeto.

12.5 Administrao de contrato

A administrao de contrato visa garantir que ambas as partes cumpram com suas
obrigaes estabelecidas. Portanto necessrio que a equipe de administrao de contrato
avalie o desempenho do fornecedor
A natureza legal da relao contratual faz com que muitas vezes essa administrao
seja uma funo administrativa separada da organizao do projeto.
A administrao de contratos tambm inclui um componente financeiro que monitora
o pagamento de recursos aos fornecedores.

22
O processo de administrao de contratos deve avaliar e documentar o desempenho
de fornecedores, tomando aes corretivas quando necessrio. Essa validao tambm
usada para determinar se o fornecedor est atendendo as suas obrigaes contratuais.
Contratos podem ser encerrados previamente por acordo mutuo, em conformidade
com os termos nele estabelecidos. Nem sempre esses aditamentos beneficiam ambas as
partes da mesma forma.
Para administrar os contratos so levados em conta os contratos, o plano de
gerenciamento de contrato, a seleo de fornecedores, os relatrio de desempenho dos
fornecedores, as solicitaes de mudanas aprovadas e as informaes sobre o
desempenho do trabalho.
As seguintes tcnicas e ferramentas so utilizadas na administrao de contratos:

Sistema de controle de mudanas no contrato para definir o processo pelo qual um contrato

pode ser modificado

Analise de desempenho conduzida pelo comprado para quantificar a capacidade ou

incapacidade do fornecedor
Inspees e auditorias
Relatrios de desempenho
Sistemas de pagamentos
Administrao de reclamaes
Sistema de gerenciamento de registros para gerenciar as documentaes de contratos
Tecnologia da informao com o objetivo de aumentar a eficcia e eficincia na
administrao de contratos.
Essas tcnicas e ferramentas irado contribuir com o plano de gerenciamento de
projetos com os seguintes documentos:

Documentao do contrato
Mudanas solicitados no plano de gerenciamento e em seus planos auxiliares
Aes corretivas recomendadas para que um fornecedor fique em conformidade com os

termos do contrato
Ativos de processos organizacionais como cronogramas de pagamentos, resultados de

auditorias, etc.
Documentao de avaliao de desempenho do fornecedor
Atualizaes no plano de gerenciamento de projeto

12.6 Encerramento do contrato

Da suporte ao processo de encerrar um contrato pelo fim do seu projeto ou pela
resciso antecipada do mesmo.

23
No caso de encerramento pelo cumprimento deste deve-se avaliar e registrar os
resultados finais e de desempenho durante a sua execuo, documentando todos os
resultados para referencias futuras
A resciso e um caso especial que pode resultar de um acordo mtuo entre as partes
ou descumprimento das obrigaes de uma das partes. Os direitos e responsabilidades das
partes em caso de resciso esto includo em uma clausula de trmino de vigncia do
contrato.
O processo de encerramento de contrato utiliza os seguintes documentos de apoio:

Plano de gerenciamento de aquisies

Plano de gerenciamento de contrato
Documentao do contrato
Procedimentos de enceramentos de contrato
O encerramentos de contratos utiliza as seguintes tcnicas e ferramentas:

Auditorias de aquisio para identificar sucessos e falhas e auxiliar na preparao ou

administrao de outros contratos de aquisio

Sistema de gerenciamento de registros
Essas ferramentas geram as seguintes contribuies no plano de gerenciamento de
projeto:

o
o
o

Contratos encerrados
Ativos de processos organizacionais:
Arquivos de contrato
Aceitao de entrega
Documentao das lies aprendidas

DESAFIO 02
11 Projeto de Arquitetura
Projetos de arquitetura so necessrios para decompor grandes sistemas em
pequenos subsistemas. A documentao explicita da arquitetura principal oferece vantagens
tais como facilidade de comunicao de stakeholders, definio precoce de requisitos no
funcionais crticos e facilidade de reuso da arquitetura em sistemas similares.
A escolha da melhor arquitetura para o sistema a ser desenvolvido depende dos
requisitos no funcionais do sistema como desempenho, nvel de proteo desejado,
segurana, disponibilidade e facilidade de manuteno.
A decomposio de um grande sistema em subsistemas e um processo difcil, que
deve levar em conta os requisitos no funcionais e estes, por algumas vezes, podem muitas

24
vezes exigir que se aplique mais de um modelo de arquitetura para se conseguir uma
soluo adequada.

11.1 Decises de projeto de arquitetura

Definir a arquitetura do sistema exige experincia, criatividade e grande
conhecimento do arquiteto sobre o assunto. Nesta definio o arquiteto dever atender
diversos requisitos funcionais e no funcionais do sistema, estabelecendo os parmetros
que o sistema ira seguir para o melhor funcionamento no ambiente para o qual ele est
sendo projetado. O engenheiro pode utilizar, em alguns casos, modelos de arquitetura
genricos, no entanto para algumas situaes ele necessitara criar modelos especficos
para chegar a uma soluo adequada.
Ao desenvolver o sistema, o arquiteto precisa j nesta fase definir se o sistema ser
baseado num modelo cliente-servidor ou camadas. A escolha depende de qual modelo ira
atender melhor aos requisitos do sistema.
O resultado deste processo ser o projeto de arquitetura. Este documento ira utilizar
recursos grficos e de escrita para definir como cara subsistema ira ser estruturado, tais
como modelos estticos de estrutura que mostra o subsistema ou componentes
desenvolvidos como unidades separadas, modelos dinmicos de processo que mostra como
o sistema est organizado em processos em tempo de execuo, modelos de interface que
define os servios oferecidos por cada subsistema por meio de interfaces pblicas, modelos
de relacionamentos que mostram os relacionamentos de fluxo de dados entre sistemas e
modelos de distribuio que mostram como os subsistemas poder ser distribudos pelos
computadores.
Existem uma linguagem para descrio de arquiteturas (ADL Architectural
Description Language) para descrever arquiteturas de sistemas, mas por ser apenas
compreendida por especialistas ela e pouco utilizada, sendo mais comum encontra notaes
como UML nas descries de arquiteturas.

11.2 Organizao de sistema

O mapeamento do subsistemas para a estrutura organizacional nem sempre
possvel, no entanto e necessrio que a organizao seja definida com antecedncia no
processo de projeto de arquitetura, pois este poder refletir-se diretamente na estrutura do
subsistema.
Sero abordados a seguir trs estilos organizacionais amplamente usados.
11.2.1 O modelo repositrio

25
Os subsistemas devem trocar informaes entre si. Isso pode ser feito
fundamentalmente de duas maneiras. Atravs de um banco de dados central acessado por
todos os subsistemas, que chamado de modelo repositrio, ou com cada subsistema
armazenado seus prprios dados e trocando informaes com os outros subsistemas
atravs de mensagens.
Algumas vantagens do sistema repositrio so:
- Eficincia ao compartilhar grandes quantidades de dados pois no h
necessidade de transmitir dados explicitamente de um subsistema para outro
- Os subsistemas no precisam saber como os dados sero usados
- Atividade de backup, proteo, controle de acesso e recuperao de erros
so centralizadas.
- O modelo de compartilhamento e visvel, facilitando a integrao de novas
ferramentas, desde que estas obedeam ao modelo do repositrio.
No entanto esse sistema tambm oferece algumas desvantagens como:
- Os subsistemas devem sempre estar de acordo com o sistema do
repositrio, o que pode dificultar ou mesmo impossibilitar integrao de novos subsistemas.
- A evoluo de do sistema pode ser difcil ou mesmo impossvel pois os
dados precisariam ser todos traduzidos de acordo com o novo modelo
- Obriga todos os subsistemas a obedecerem a mesma poltica de proteo,
backup e recuperao.
- Pode ser difcil distribuir o repositrio por uma srie de maquinas, o que
pode gerar redundncias ou inconsistncia de dados.
11.2.2 O modelo cliente-servidor
Neste sistema um ou mais servidores fornecem servios ou dados aos subsistemas.
Os clientes precisam saber quais servidores fornecem os servios ou os dados que eles
necessitam sendo assim os servidores devem possuir um endereo conhecido. Em
contrapartida os servidores no precisam conhecer o endereo dos clientes, basta que o
cliente se comunique com ele utilizando um protocolo e autenticao adequada.
A grande vantagem desse modelo e a possibilidade de usar diversos processadores
e pode adicionar novos servidores e integra-los ao sistema sem afetar as outras partes.
A utilizao de modelos de dados especficos em cada servidor pode gerar uma
dificuldade de comunicao entre eles, exigindo assim a utilizao de um protocolo comum
de comunicao, com por exemplo o XML, isso, no entanto, pode gerar problemas de
desempenho.
11.2.3 O modelo em camadas
Neste modelo, o sistema e dividido em camadas, cada uma fornecendo um conjunto
de servios especficos. Uma maneira de implementa-lo e definir um cdigo de mquina

26
ideal, essa linguagem abstrata seria traduzida posteriormente numa linguagem de mquina
real.
Esse modelo favorece o desenvolvimento incremental do sistema e a portabilidade.
Uma camada precisa se comunicar unicamente com a camada superior e posterior a ela
mesma. Isso faz com que uma camada possa ser substituda por outra equivalente.
Entre os problemas desse modelo est na dificuldade de projeta-lo e tambm em
possveis problemas de desempenho devido aos vrios nveis de interpretao de
comandos que podem existir.

11.3 Estilos de decomposio modular

Aps escolher a organizao geral do sistemas iremos decidir sobre a abordagem
que usaremos nos mdulos do sistema. Aqui podemos utilizar os mesmos estilos
explicados na sesso 11.2.
Embora no exista uma clara distino entre subsistemas e mdulos podemos
pensar no subsistema com um sistema em si, cuja operao no dependa de outros
subsistemas. Por outro lado o modulo e um sistema q fornece um ou mais servios a outros
mdulos e faz uso de servios fornecidos por outros mdulos.
Podemos utilizar duas estratgias principais para decomposio dos mdulos:
Decomposio orientada a objeto Pipelining onde os mdulos so decompostos orientados
a funes.
As duas estratgias permitem uma execuo sequencial ou paralela, no entanto
devemos evitar a definio prematura sobre a simultaneidade do sistema.
11.3.1 Decomposio orientada a objeto.
Na decomposio orientada a objeto os objetos so criados a partir de classes de
objetos com seus atributos e operaes bem definidas. Isso permite que devido a
independncia de objetos seja possvel alterar o funcionamento de um objeto sem afetar aos
demais. Outra vantagem e a facilidade de compreenso, pois, com frequncia, os objetos
so representaes de entidades do mundo real.
Por outo lado, mudanas no sistema que precisam mexer com as interfaces dos
objetos podem afetar diversos objetos, necessitando assim de uma avaliao mais rigorosa
dos seus impactos. Outra desvantagem e que objetos muitos complexos no mundo real
podem ser difceis de representar como um objeto.
11.3.3 Pipelining orientado a funes
Neste modelo os dados so enviados de uma funo para outra e transformados at
serem convertidos em uma sada. Essas transformaes podem ocorrer de forma

27
sequencial, num estilo chamado de duto (pipe) e filtro ou de forma paralela, chamado de
lote.
As vantagens dessa arquitetura so o reuso de informaes, a facilidade de
compreenso pois os trabalhos so processados em termos de entrada e sada de dados, a
evoluo do sistema de forma direta e a simplicidade de implementao.
O grande problema nesse estilo e que o formato de transferncia de dados de
entrada e sada precisa ser padronizado. Caso os dados de entrada ou sada sejam
incompatveis pode ser impossvel integrar novas transformaes.
Traduzir sistemas interativos ou interfaces grficas que dependem de eventos
gerados pelos usurios para pipelining pode ser muito difcil este modelo exigir uma
sequncia de dados a ser processada.

11.4 Modelos de controle

Os modelos de controle definem como o sistema fara a comunicao entre os
subsistemas garantindo que as informaes sejam entregues de maneira correta.
De forma genrica podemos definir esses estilos como Controle centralizado e
Controle baseado em eventos.
11.4.1 Controle centralizado
Neste modelo um subsistema tem a responsabilidade pelo gerenciamento e
execuo de todos os outros. Esse modelo divide-se em duas classes
1 Modelo chamada-retorno: Neste modelo um subsistema ir fazer a chamada do
prximo. Assim que o subsistema requisitado tiver terminado ele ir retornar o controle para
o sistema que o requisitou.

Dessa forma ele indicado apenas para programas

sequenciais. Este um sistema rgido, que dificulta lidar com excees, por outro lado e
relativamente fcil analisar o fluxo de dados uma vez que a funo sempre retornara ao
ponto em que foi solicitada.
2 Modelo gerenciador: E aplicvel a sistema concorrentes. Um processo e um
subsistema ou modulo que pode ser executado paralelamente a outros. Neste modelo o
gerenciador fica constantemente verificando o estado das variveis do sistema e assim
determina quando os processos devem parar ou iniciar. Por estar constantemente varrendo
o estado do sistema e frequentemente chamado de modelo evento-loop.
11.4.2 Sistemas orientados a eventos
Neste sistema as decises so baseadas em eventos externos gerados pelo
sistema. Esses eventos podem assumir uma gama de valores baseados em um menu.
Abordaremos os modelos de broadcast e modelos orientados a interrupes.

28
Nos modelos de broadcast os subsistemas registram no tratador de eventos o
interesse em eventos especficos. Assim quando um evento ocorre qualquer subsistema que
tenha interesse no evento poder responder a ele. A funo do controlador de eventos e
basicamente garantir que os subsistemas saibam quando os eventos ocorrem. O tratador
poderia simplesmente enviar todos os eventos a todos os subsistemas, mas isso pode gerar
uma sobrecarga no sistema comprometendo o seu desempenho.
A vantagem desse sistema e que novos subsistemas podem facilmente se registrar
para responder a um evento, bastando comunicar ao tratador de eventos.
A grande desvantagem e que vrios subsistemas podem responder simultaneamente
ao mesmo evento podendo assim causar conflitos quando os resultados da manipulao do
evento forem apresentados.
Esse sistema e muito utilizado em sistemas de tempo real, onde eventos externos
necessitam de respostas imediatas.

11.5 Arquiteturas de referncia

Os modelos vistos at o momento so modelos gerais. Podemos utilizar modelos
mais especficos, que se aplicam a um determinado domnio de aplicaes.
Estes modelos especficos podem ser divididos, embora no exista uma distino
rgida entre eles, entre Modelos genricos e Modelos de referncia.
Os modelos genricos representam as principais caractersticas de uma srie de
sistemas reais.
Os modelos de referncia so mais abstratos e englobam uma classe maior de
sistemas. Diferente dos modelos genricos no so considerados roteiros de implantao,
mas sim uma forma de comparao para sistemas de um mesmo domnio.
Lembramos que por no haver uma distino rgida entre esses modelos, possvel
utilizar modelos genricos como modelos de referncia em algumas situaes.

29

12 - Arquiteturas de Sistemas Distribudos

Os sistemas distribudos esto se tornando predominantes em grandes sistemas.
Podemos destacar as seguintes vantagens sobre sistemas distribudos:
1. Compartilhamento de recursos de software e hardware em uma mesma rede.
2. Abertura, permitindo que software e equipamentos de diferentes fabricantes sejam
combinados
3. Concorrncia, permitindo vrios processos simultneos em diferentes computadores
4. Escalabilidade, facilitando o crescimento do sistema quando necessrio.
5. Tolerncia a defeitos, pois devido ao uso de vrios hardwares e softwares uma falha
completa no sistema tende a ocorrer somente devido a uma falha de rede.
Por outro lado podemos citar as seguinte desvantagens desse sistema.
1. Complexidade, sua distribuio torna mais difcil a compreenso dos fatores de
desempenho do sistema, principalmente por este ser influenciado pela largura de banda da
rede e volume de dados em trafego.
2. Proteo, pois devido a granularidade os dados em circulao esto mais sujeitos a ataques
ou interceptaes.
3. Gerenciamento deste sistema e mais complexo, pois as maquinas e verses de software em
operao podem ser diferentes.
4. Imprevisibilidade.
5. Imprevisibilidade, pois a carga a qual o sistema est submetido em um dado momento pode
influenciar significativamente o tempo de resposta do mesmo.
Dois tipos genrico de abordagens que ajudam no projeto de sistema distribudos so a
arquitetura cliente-servidor, onde o sistema e pensado como um conjunto de servios
fornecidos a clientes sendo que os clientes devem necessariamente conhecer o endereo
dos servidores, e a arquitetura de objetos distribudos, onde o sistema interage com um
conjunto de objetos que interagem e cuja localizao e irrelevante.
Alm das abordagens citadas temos ainda a arquitetura ponto a ponto a arquitetura
orientada a servios. Ambas mais voltadas a ambientes de sistemas pessoas e intraorganizacional.
Pelo fato de sistemas distribudos poderem interagir com diferentes softwares e
hardwares eles valem-se do uso de um software intermedirio para fazer a comunicao
entre as diferentes partes do sistema. Esse software chamado de middleware. Um
exemplo de middleware so os softwares gerenciadores de banco de dados.

12.1 Arquitetura de multiprocessadores

30
O modelo mais simples de sistemas distribudos e o de multiprocessadores.
Comumente utilizado em sistemas de tempo real, neste sistema o uso de um escalonador,
para que as tarefas fossem executadas de acordo com a prioridade em um nico
processador, as tarefas do sistema so distribudas para diferentes processadores de forma
pr-determinada em sistemas crticos ou atravs de um dispatcher que decide para que
processador a tarefa ser alocada.

12.2 Arquitetura cliente-servidor

Neste modelos os clientes no precisam saber da existncia dos outro clientes uma
vez que estes se comunicam e precisam saber apenas da existncia do servidor que
fornece o servio desejado.
Por outro lados os servidores podem se comunicar com vrios clientes
simultaneamente e no precisam saber a localizao destes, pois o incio da troca de
informaes ser sempre feita atravs de respostas aos requerimentos dos clientes, ao
servidor necessrio apenas saber quem solicitou e qual a informao desejada.
O modelo mais simples desta arquitetura o de duas camadas, ou seja, e composto
apenas de uma camada de servidores e uma de cliente. Pode assumir a forma de modelo
cliente-magro onde o cliente e responsvel apenas pela interface de apresentao e todo o
processamento realizado no servidor ou na forma cliente-gordo na qual todo o
processamento dos dados executado no cliente, cabendo ao servidor apenas o
gerenciamento de dados.
A forma cliente-magro tem como vantagem no ter muitos requisitos quanto a
mquina do cliente, uma vez que todo o processamento realizado pelo processador do
servidor, no entanto isso poder sobrecarregar o servidor causando lentido e instabilidade
no sistema.
O modelo cliente-gordo utiliza-se da capacidade de processamento dos dispositivos
modernos, liberando assim a carga do servidor e das redes, pois caber ao servidor apenas
gerenciar os dados enquanto o cliente realiza todo o processamento lgico. O problema
causado por este modelo a distribuio da funcionalidade por diversos equipamentos,
sendo assim qualquer alterao que se faa necessria exigira a reinstalao do software
em todos os clientes.
Uma forma de solucionar os problemas dos modelos cliente-magro e cliente-gordo e
utilizar um modelo cliente-servidor com trs camadas. Nesse modelo ao invs de acumular
funes no cliente ou no servidor, cada camada seria responsvel por uma. O cliente seria
responsvel apenas pela apresentao, uma camada intermediaria faria o processamento
lgico (servidor de processamento) e por fim teramos o servidor de dados. Este modelo
ainda pode ser estendido a diversas camadas de acordo com a necessidade, por exemplo,

31
do uso de diversos bancos de dados e compatibilidade entre diferentes sistemas para o
processamento dos dados.

12.3 Arquiteturas de objetos distribudos

Neste modelo no fazemos distino entre cliente e servidor. Ambos so tratados
como objetos que se comunicam atravs de um middleware chamado de requisitos de
objetos, que ir fornecer uma interface continua e transparente para comunicao entre os
objetos.
Este modelo oferece as seguintes vantagens:
1234-

Permite ao projetista postergar decises sobre onde e como servios sero oferecidos.
Facilita a incluso de novos recursos desde que este se comunique com o middleware.
Torna o sistema mais flexvel pois os objetos podem ser independentes entre si.
Possibilidade de configurar o sistema dinamicamente atravs da migrao dos objetos
quando necessrio.
Esse tipo de abordagem pode facilmente implementar um sistema cliente-servidor de
duas ou mais camadas, mas nesse caso os clientes e servidores seriam tratados apenas
como objetos e no de forma distinta pelo middleware integrador.
Esse sistema oferece como vantagem a versatilidade de adicionar bancos de dados
ou distribui-los em vrios computadores uma vez que eles sero tratados apenas como
objetos pelo sistema e tambm permite a fcil expanso do sistema atravs da incluso de
novos objetos integradores, que no precisam conhecer o funcionamento dos demais
integradores pois iro comunicar-se apenas com os objetos que ir integrar.
A grande dificuldade deste sistema e a complexidade pois tendem a refletir
transaes humanas especializadas e ainda existe uma experincia muito pequena em
relao ao projeto e desenvolvimento de negcios de alta granularidade.

12.3.1 CORBA
CORBA e um padro de middleware definido pela OMG (Object Management
Group), que define padres para o desenvolvimento orientado a objeto, para permitir a
comunicao em nvel logico entre objetos de plataformas diferentes.
A viso da OMG sobre uma aplicao distribuda abrange uma serie de componentes
que so atendidos pelos modelo CORBA.
Os modelos CORBA consideram o objeto como um encapsulamento de atributos e
cria atravs de uma Linguagem de Definio de Interface (IDL) um objeto contendo os
atributos e mtodos pblicos do objeto. Desta forma quando um objeto necessitar de acesso
a servios ou dados de outro objeto, ele ir ser referenciar ao objeto CORBA referente ao
objeto que ele deseja para ter acesso aos dados

32
Um requisitor de objetos (ORB Object Request Broker) cuidara da comunicao
dos objetos desta forma os objetos no precisaram conhecer a implementao ou a
localizao doe demais objetos.
Para o ORB localizar o objeto e necessrio que cada objeto possua um esqueleto de
IDL e stubs de IDL para cada objeto usado. Cada computador que ir processar os dados
precisara de um requisitor de objetos.
A iniciativa CORBA d de 1980 e define aproximadamente 15 servios comuns para
aplicaes distribudas orientadas objetos, entre eles:

Servios de definio de nomes e de negcio que permitem que os objetos se refiram uns

aos outros.
Servios de notificao que permitem aos objetos notificar outros objetos de que algum

evento ocorreu
Servios de transao que apoiam transaes em caso de falhas.

12.4 Computao interorganizacional distribuda

Inicialmente por motivos de proteo e interoperabilidade os sistemas distribudos
eram intra-organizacional. Com os modelos mais novos de computao distribuda surgiram
modelos interorganizacionais, tais como os modelos ponto a ponto e modelos baseados em
funes.

12.4.1 Arquiteturas ponto a ponto

Nesta arquitetura sistemas descentralizados no existe uma diferena clara entre
cliente e servidor uma vez que qualquer ponto da rede pode estar ciente de todos os demais
e requisitar dados de todos eles.
As aplicaes mais comuns so em sistemas domsticos como o Kazaa e sistemas
de torrente atuais.
No entanto j existem estudos sobre as aplicaes comerciais e cientificas que
requerem uma grande capacidade de processamento.
Embora em teoria os sistemas ponto a ponto digam que todos os ns so iguais isso,
na pratica, impossvel pois ser necessrio sempre a implantao de ns que sirvam
como pontes que iro guiar o sinal de um n para outro.
Essa arquitetura oferece como vantagem a sua redundncia, tornando-a resistente a
erros e falhas de rede. No entanto essa mesma redundncia tambm ira gerar um overhead
no sistema.
Como soluo para isso foi desenvolvida uma arquitetura ponto a ponto
semicentralizada, com um servidor que ir auxiliar na conexo entre os pares da rede.

33
Mesmo com os problemas de overhead, o sistema ponto a ponto ainda uma
abordagem mais eficiente para a computao interorganizacional que o sistema orientado a
servios que no necessitem de alto grau de confiabilidade e segurana.
12.4.2 Arquitetura de sistema orientada a servio
O desenvolvimento da WEB facilitou o acesso de computadores clientes a servidores
remotos. Isso fez com que fosse necessrio desenvolver formas que permitissem o dilogo
entre eles atravs da WEB.
A soluo encontrada foi a criao de WE Services. Este servio padroniza alguns
recursos computacionais permitindo assim que as informaes possam ser usadas por
outros programas.
Neste modelo um provedor definira uma interface de definio e implementara toda a
funcionalidade do servio. A aplicao solicitante fara a chamada atravs de um cdigo e ir
processar o resultado da chamada.
As diferenas entre o modelo de servio e a abordagem de objetos distribudos so:

Os servios podem ser oferecidos por qualquer provedor, independentemente de sua

localizao desde que sigam os padres estabelecidos

As informaes se tornam publica a quem tem autorizao, no havendo necessidade de

negociao
Os provedores de servios podem ser mudados dinamicamente enquanto o servio est em

execuo.
fcil criar novos servios.
Os servios podem ser comprados pelos usurios
O tratamento de excees pode se tornar um servio externo nas aplicaes.
As aplicaes podem mudar mais facilmente de acordo com o ambiente utilizando
servidores diferentes.
Os Web services dependem de trs padres fundamentais baseados em UML

1. SOAP (Simple Object Acess Protocol) que define uma organizao para troca de dados.
2. WSDL (web Services Description Language) Que define a apresentao das interfaces
3. UDDI (Universal Description Recovery) Padro para descobrimento de servios.
Os Web services so totalmente independente das aplicaes que os usam, sendo
assim podem ser construdos sistemas totalmente baseados em Web services ou mistos,
com partes utilizando Web services e partes sendo executadas localmente.
Como vantagens do Web services temos a flexibilidade, podendo programar o
servio para localizar servidores de acordo com condies pr-estabelecidas.

34

13 Arquitetura de aplicaes
Negcios similares ou de um mesmo ramo tendem a ter necessidades e solues
parecidas. A diferena se restringe aos detalhes e funes especificas.
Projetistas de softwares podem utilizar arquiteturas genricas de vrias maneiras:
como um ponto de partida para o processo de projeto e arquitetura, como checklist do
projeto, organizar o trabalho da equipe de desenvolvimento, avaliar o reuso de componentes
ou mesmo vocabulrios para conversar sobre os tipos de aplicaes.
Da mesma forma que os sistemas, a arquitetura de algumas aplicaes tambm
muito similar quando se examina mais de perto. Assim as aplicaes de processamento de
dados, processamento de transaes, processamento de eventos e processamento de
linguagens podem ser classificadas como grandes grupos de aplicaes.
Devemos lembrar que embora esses grupos cubram quase todos os modelos de
software que iremos desenvolver, softwares mais complexos dificilmente podero ser
modelados utilizando-se um nico modelo. Teremos ento sistemas hbridos com
subsistemas utilizando diferentes modelos que sero integrados dentro do sistema como um
todo.

13.1 Sistemas de processamento de dados

Esses sistemas trabalham normalmente com bancos de dados que muitas vezes so
maiores que o prprios sistema. Se encarregam de gerenciar as entradas e sadas de dados
podendo tomar aes especificas de acordo com os valores de dados resgatados ou
armazenados.
Esse sistema composto por um componente de entrada de dados do banco de
dados ou de um perifrico de entrada, outro componente para processar os dados
recebidos, e por fim o componente para sada do dado, seja para um banco de dados ou
para um perifricos externo.
As transaes nesses sistema so processadas de maneira linear, e portanto,
naturalmente orientados a funes. Portanto, o sistema sempre seguira uma determinada
ordem desde a entrada dos dados, passando por seu processamento at gerar a sada.
A arquitetura desse tipo de sistema e relativamente simples. Sua complexidade e
formada pela estrutura dos dados a serem processados e no pela arquitetura do programa
em si.

35

13.2 Sistema de processamento de transaes.

Desenvolvidos para processamento de solicitaes de informaes por usurios de
um banco de dados ou solicitaes
Antes de um dado ser inserido em definitivo no banco de dados, necessrio validar
os dados e as solicitaes feitas, garantindo assim, que somente dados validos sero
efetivamente salvos no banco de dados, evitando inconsistncias. Essa e a funo de um
sistema de processamento de transaes. Ele verifica todas as solicitaes feitas ao banco,
verifica a integridade da solicitao, a integridade dos dados, e somente depois de validada
a transao concluda pelo usurio e salva no banco de dados.
Em sistemas muito grandes, que necessitam interao com diferentes fontes
necessrio utilizar um middleware para fazer a integrao do sistema, no formato visto no
captulo anterior.
13.2.1 Sistemas de gerenciamento de informaes e recursos.
So sistemas que permitem o acesso controlado a uma grande base de informaes
sobre recursos finitos.
So usados por exemplo na administrao de hospitais para controle dos quartos,
entrada e sada de pacientes, em consertos, cinemas, bibliotecas, etc.
Pode ser formado por vrias camadas, mas comumente,

encontramos

principalmente uma camada de login, um camada de gerenciamento de consultas, um

camada de gerenciamento de recursos de sada e uma camada de interface com o usurio.
Sistemas de alocao de recursos so compostos pelos seguintes componentes:
1.
2.
3.
4.
5.
6.
7.
8.

Um banco de dados que mantem detalhes sobre os recursos alocados,

Um conjunto de regras para alocao de recursos.
Um componente de gerenciamento de recursos
Um componente de alocao de recursos
Um modulo de autenticao de usurios
Um modulo de gerenciamento de consultas
Um componente de entrega de recursos
Um componente de interface com o usurio.
A implantao desses sistemas pode ser feita atravs da execuo em um nico
computador, fazendo com que a comunicao com o banco de dados seja feita atravs de
um nico programa. Outra alternativa e atravs de componentes de baixa granularidade
como Web services, que fica responsvel por todas as comunicaes com o usurio.

36

13.3 Sistemas de processamento de eventos

Sistemas de processamento de eventos respondem a entradas ou acontecimentos
externos que exigem uma resposta do sistema. Em geral eles respondem por
acontecimentos imprevisveis e, portanto, normalmente so organizados como um conjunto
de processos que monitoram e do resposta aos acontecimentos. So comumente usados
em qualquer sistema que precise de resposta em tempo real as entradas ou aes do
usurio.

13.4 Sistema de processamento de linguagens

So sistemas que aceitam a entrada de uma linguagem natural ou artificial e geram
uma ou representao dessa linguagem como sada. Um exemplo desse sistema so os
compiladores e tradutores usados na programao de softwares.
Os componentes de uma arquitetura genrica de um sistemas de processamento de
linguagens so:
1.
2.
3.
4.
5.
6.

Analisador lxico que verifica a validade das palavras

Tabela de smbolos validos para a linguagem
Analisador sinttico quer verifica a validade da linguagem sendo traduzida
Uma arvore de sintaxe que representa o programa a ser compilado
Um analisador semntico faz correo sinttica do texto de entrada
Gerador de cdigo que gera a linguagem de mquina abstrata

37

29 Gerenciamento de configuraes
Ao desenvolvermos um sistemas so geradas diversas verses deste devido a
mudanas de hardware, correo de erros etc. Portanto o gerenciamento de configuraes
(CM Configuration Management) torna-se fundamental para evitar correes e alteraes
em verses erradas do sistema ou a entrega de uma verso errada do sistema atravs de
tcnicas para registro e processamento das mudanas. O gerenciamento de configuraes
garante a rastreabilidade das verses do sistema.
Gerenciamento de configuraes com frequncia considerado parte da garantia de
qualidade do software sendo essencial para os principais padres de qualidade no mercado
atual.
O gerenciamento de configuraes pode ser usada em formas mais completas e
burocrticas, que, embora desacelerem o andamento do projeto, garantem um controle
rgido para manter a rastreabilidade no sistema. No entanto, quando um desenvolvimento
gil necessrio o gerenciamento de configuraes no deve ser completamente
abandonado. Nestes casos devemos utilizar formas mais simples de gerenciamento de
configuraes para que mantenhamos algum controle sobre as verses de construo do
sistema.

29.1

Planejamento

de

gerenciamento

de

configuraes
O plano de gerenciamento define os padres para serem usados no gerenciamento.
Nele devem constar o que ser gerenciado no prometo, o responsvel pelos procedimentos
de gerenciamento, as polticas que sero aplicadas a equipe, as ferramentas utilizadas pra o
controle e a estruturas de banco de dados para registrar as informaes.
Outras informaes podem sem includas de acordo com a necessidade do sistema
e grau de controle desejado.
29.1.1 Identificao de item de configurao
No desenvolvimento de um grande sistema sero gerados milhares de arquivos,
muitas vezes com vrias verses do mesmo arquivo. O gerenciamento de configuraes
deve garantir que no arquivos de mesmo nome sejam identificados de forma correta
quando forem solicitados.

38
Uma tcnica para isso o uso de hierarquizao dos arquivos, evidenciando a
relao entre os itens e garantindo que documentos relacionados possuam uma mesma
raiz. uma maneira simples e de fcil compreenso para organizar os arquivos.
29.1.2 Banco de dados de configurao
Um banco de dados de configurao deve conter os dados para relatrios de
gerencia e conter dados que permitam analisar os impactos das mudanas no sistema. Para
isso o banco de dados deve-se utilizar de formulrios que contenham respostas para as
questes mais recorrentes, como, por exemplo:
1.
2.
3.
4.
5.
6.

Quais clientes pegaram uma verso especifica do produto

Qual a verso para um determinado tipo de hardware
Quantas verses o sistema possui
Quais verses sero afetadas pela alterao em um componente
Quantas solicitaes de alterao esto pendentes para determinada verso do sistema
Quantos defeitos foram reportados em uma determinada verso.
O sistema de banco de dados e uma soluo barata e flexvel, o grande problema q
no existe maneiras segura de garantir que o banco de dados ser atualizado a cada
alterao do sistema.

29.2 Gerenciamento de mudanas

Devido as necessidade organizacionais mudanas so inevitveis para grande
sistemas de software. Isso faz com que seja fundamental ferramentas para o gerenciamento
de mudanas.
Procedimentos de mudana devem passar por uma anlise prvia atravs de um
formulrio de solicitao (CRF Change Request Form). Atravs deste ser avaliado o
custo benefcio da mudana e sua viabilidade. Todo o formulrio de mudana deve ser
registrado imediatamente no banco de dados, e assim que for analisada seu status
atualizado. Em caso de rejeio deve constar o motivo desta.
Para mudanas validas, uma vez aprovadas devem ser submetidas ao comit de
controle de mudanas (CCB Change Control Board), exceto em casos de mudanas
menores como erros de tela. Este comit pode ser formado por tcnicos seniores dos
clientes e fornecedores e fundamental ser formalizado em projetos de reas crticas.
Para sistemas genricos o cliente irrelevante no gerenciamento de mudanas,
sendo que as solicitaes de mudanas geralmente so feitas por erros e falhas
descobertos no sistema.
Para mtodos como o extreming programming a participao do cliente e
fundamental para definir se a mudana ser implementada e qual a sua prioridade mediante
as demais caractersticas do sistema.

39
Os componentes devem manter uma precedncia histrica de suas alteraes, o que
pode ser feito atravs de comentrios padronizados no prprio cdigo fonte.

29.3 Gerenciamento de verses e releases

Um sistema pode ter diversas verses com caractersticas prprias que vo desde
uma funo especifica a compatibilidade com determinado tipo de hardware.
Sendo assim e fundamental manter um controle das verses existentes e qual
release cada cliente recebeu afim de evitar alteraes em verses erradas ou envio de
releases alterados para clientes que tem funes especificas.
Um sistema normalmente possui muito mais verses que release, uma vez que as
verses podem ser criadas apenas para testes internos, ao passo que as releases recebem
apenas modificaes aprovadas e testadas antes da liberao para os clientes.
29.3.1 Identificao das verses
A verso de um sistema especifica quais so as verses dos componentes includas
nela. Essa identificao deve ser feita de maneira no ambgua
Trs tcnicas bsicas para identificao da verso do componente so:
1. Numerao de verses com componente recebendo um nmero explicito e unido de verso.
2. Identificao baseada em atributos onde os componentes so identificados pela combinao
do nome e valor dos seus atributos.
3. Identificao orientada a mudanas onde considera-se que cada mudana atende a uma
solicitao e a verso e criada pela combinao do nome, valor de atributos e solicitao de
mudana.
29.3.2 Gerenciamento de releases
Release e uma verso do sistema distribuda aos clientes que pode conter arquivos
de configurao, arquivos de dados, programas de instalao, documentao eletrnica e
em papel, empacotamentos ou publicidade.
Na distribuio de um release no podemos contar que releases anteriores esto
instalados no cliente, cada release deve ser independente ou conter os dados necessrios
dos anteriores.
A deciso sobre liberaes de um release deve levar em conta diversos fatores
como: qualidade tcnica do sistema, o tipo de software, mudanas de plataforma,
incrementos na funcionalidade, competio, requisitos de marketing, propostas e
necessidades de mudanas do cliente.
Ao liberar um release ele deve ser documentado de forma a poder ser recriado no
futuro. Suas funes especificas de componentes de cdigo-fonte e cdigo executvel,

40
arquivos de dados e de configurao devem ser documentados e armazenados permitindo a
recriao deste mesmo aps vrios novos releases.

29.4 Construo de sistemas.

A construo de sistema e o processo de compilao e ligao dos componentes.
Nele deve-se garantir que os componentes, arquivos, arquivos de dados referenciados pelo
componente esto devidamente includos e principalmente, com suas verses corretas.
Tambm deve-se tomar cuidado quanto a disponibilidade verso e compatibilidade das
ferramentas usadas para desenvolver o sistema.
Existem hoje ferramentas automatizada definidas pela equipe de CM que ajudam
nesse processo atravs de scripts que garantem a dependncia e compatibilidade dos
componentes.

29.5 Ferramentas CASE para gerenciamento de

configuraes
Uso de ferramentas CASE n o processo de gerenciamento de configurao nas
diferentes verses ajuda a evitar erros que podem prejudicar o sistema. Essas ferramentas
combinadas podem criar um apoio para as atividades de CM atravs de reas de trabalho
de 2 tipos.
Abertos: ferramentas integradas a cada estgio atravs de procedimentos
organizacionais padronizados para essas ferramentas.
Fechados: incluem um banco de dados integrado ao CM, facilitando o controle de
verses e a construo do sistemas. No entanto so complexos e dispendiosos dificultando
o seu uso.
29.5.1 Apoio para gerenciamento de mudanas
Com vrias pessoas envolvidas no projeto e necessrio que elas possuam um
maneira de comunicar mudanas umas s outras.
Uma ferramenta de apoio precisa dos seguintes itens bsicos: editor de formulrios
com propostas de mudanas, um sistema de workflow para o recebimento e processamento
dos formulrios, um banco de dados de mudana que gerencie as propostas de mudanas e
um sistema de relato de mudanas que gere relatrios gerenciais sobre os status das
solicitaes de mudanas enviadas.

41
29.5.2 Apoio para o gerenciamento de verses
O gerenciamento de verses exige que uma grande quantidade de informaes seja
gerenciada de forma correta. Desta forma todo o sistema de apoio para gerenciamento de
verses deve conter:
1.
2.
3.
4.

Identificao das verses e releases

Gerenciamento de armazenamento das diversas verses
Registro do histrico de mudanas
Desenvolvimento independente permitindo desenvolvimento de mltiplas verses do

sistema simultaneamente.
5. Suporte a mltiplos projetos e mltiplos arquivos.

29.5.3 Suporte para construo de sistemas

Essas ferramentas visam automatizar o processo garantindo assim um grande ganho
de tempo e diminuindo as chances de erros humanos em sistemas muito grandes.
Ferramentas de construo de sistemas derivadas de ferramentas CASE devem
conter:
Linguagem de especificao de dependncia e um interpretador associado
1. Seleo de ferramenta e apoio instanciao
2. Compilao distribuda
3. Gerenciamento de objetos derivados

42

DESAFIO 3
Desafio 3.1
JSF (Java Server Faces) um framework que utiliza o padro MVC (Model, View,
Control) para criar interfaces grficas grficas do usurio (GUI). dividido em dois
componentes, a API que define a interface, eventos, converso de dados, suporte para
navegao, etc. e as tags customizadas que representam objetos em paginas JSP
Struts um framework open source para desenvolvimento de aplicaes web.
Assim como o JSF tambm foi desenvolvido para utilizar a arquitetura MVC na criao de
paginas WEB. Com o uso do Struts possvel desenvolver empregando outas tecnologias
como o Ajax e SOAP. Possui duas verses o Struts 1 mais voltado a soluo de problemas
comuns e o Struts 2.x para a soluo de problemas complexos que exigem solues
sofisticadas.
Stripes Tambem um framework open source para desenvolvimento de
aplicaes WEB. Tem a vantagem sobre outros frameworks por no necessitar uma grande
quantidade de configuraes. Dessa forma esse framework se destaca pela facilidade de
uso e as ferramentas que fornece para desenvolvimento de java na WEB.
Wicket - Viabiliza o uso de POJO (Plain Old Java Object) para desenvolvimento de
aplicaes web. Com este framework possvel desenvolver em Java para web sem
necessidade de uma ferramenta de edio ou configurao de tags especificas e com um
mnimo de conhecimento deste framework.
Tapestry - Voltado principalmente para a criao de paginas dinmicas ele
complementa a API Java Sevlet Conatiner. Este framework torna-se responsvel pelo
gerenciamento e acionamento de estados para clientes e servidores, validao de entrada
de dados, localizao e internacionalizao e gerao de relatrios de excees.
Velocity um framework de motor de modelo. Com este framework os
desenvolvedores tem a sua disposio uma linguagem poderosa, mas simples, de
linguagem de modelo para referenciar objetos em cdigo Java. Este framework tambm
utiliza o padro MVC para separar as camadas. A separao de cdigos criadas por este
framework simplifica a manuteno de pginas web. Tambm pode ser uma alternativa
vivel ao JSP e PHP.
O Velocity um framework de motor de template (modelo) para a linguagem Java.
Permite que qualquer desenvolvedor possa usar uma linguagem simples, embora poderosa,
linguagem de template para referenciar objetos definidos em cdigo Java. Usa o padro
MVC criando uma separao entre as camadas de apresentao desenvolvida por web

43
designers e a lgica de controle desenvolvida em Java. O Velocity separa o cdigo das
pginas webs, criando pginas web de mais fcil manuteno, viabilizando assim todo o
ciclo de vida do site. Fornece tambm uma alternativa vivel entre JSP (Java Server Pages)
ou PHP.
Hibernate (HIBERNATE, 2009) um framework para persistncia de objetos.
Possui um alto desempenho na utilizao do modelo relacional e servios de consultas. Este
framework faz a integrao do modelo orientado objeto com o modelo relacional. Com sua
utilizao possvel aproveitar os conceitos de herana, polimorfismo, composio e
colletctions. Sua vantagem sobre outros frameworks de persistncia que o Hibernate no
busca esconder o SQL, mas sim fornecer uma maneira fcil de integrar aplicaes orientada
a objetos ao SQL.
VRaptor Este um framework brasileiro, desenvolvido por alunos da USP que vem
ganhando espao no mundo Java. Sua funo e ser um controlador MVC, eliminando tempo
de trabalho que se perderia com cdigo repetitivo como validaes, converses,
direcionamentos e lookups. um framework que trabalha muito bem com o JSP na camada
de apresentao e com o Hibernate na camada de persistncia, tornando-o uma maneira
simplificada de trabalhar com programaes para Web.

Desafio 3.2
Frameworks apresentam inmeras vantagens para o desenvolvimento Web, como ganho de
produtividade, menor possibilidade de erros, maior integrao com outras aplicaes,
aumento da segurana.
Com relao as desvantagens h muito pouco a se dizer. Existem algumas alegaes mas
que no se mantem mediante uma anlise mais apurada, como por exemplo, que so
menos seguros, pois se descobrirem uma falha de segurana seu sistema estar
comprometido, o que verdade. No entanto pelo fato de serem usados e tesados
massivamente e em sua imensa maioria possurem cdigos abertos eles tendem a ter um
alto nvel de segurana e poucas falhas.
Uma desvantagem real uma pequena perca no desempenho do sistema. Mas isso se
torna imperceptvel ao usurio, at mesmo porque muitos frameworks oferecem recursos
para que o desempenho seja melhor com eles do que sem eles.
Outra fonte de dificuldades na utilizao de frameworks vem do fato de alguns deles
exigirem muitas configuraes por pgina. O que pode exigir muito treinamento da equipe e
tambm torna seu uso pouco atraente para pequenas aplicaes, no entanto, existem

44
frameworks que exigem pouca ou nenhuma configurao especial. Portanto a vantagem ou
desvantagem vai depender de usar a ferramenta adequada ao projeto.

Desafio 3.3
Para implementar e disponibilizar uma aplicao web e necessrio a implementao
ou utilizao de um web Service. Web servios so aplicaes que tornam-se servios na
internet, podendo assim serem acessadas por qualquer pessoa. Eles no incluem a parte
grfica, fornecem apenas servios para que as aplicaes possam ser disponibilizadas na
internet.
Para que as aplicaes se comuniquem com o web servisse elas precisam
implementar um protocolo SOAP (Simple Object Acess Protocol) conforme definido no W3C.
A utilizao deste protocolo e a garantia de independncia para o web service. Ainda
precisaremos implementar no web service suas regras de acesso

e retorno. Essas

implementaes so feitas em um arquivo XML de acordo com os padres WSDL (Web

Description Language).
Os web services estaro permanentemente aguardando requisies, portanto, sero
obrigatoriamente executados em um servidor. O Tomcat e bem difundido para este
propsito.
Uma vez definidos os protocolos de web service e configurado o servidor, estamos
prontos para implementar e disponibilizar aplicaes na web.

45

DESAFIO 4
Levando-se em conta o porte do sistema a ser desenvolvido na China Telecom
considera-se o Model-View-Controler uma padro adequado para atender aos requisitos do
projeto.
Este modelo baseia-se em uma estrutura de trs camadas separando assim o
sistema em componentes distintos:
1. Control Controlador: responsvel por interpretar as entradas de teclado ou mouse
enviadas pelo usurio e transforma-los em comandos validos que sero enviados a camada
modelo
2. Model Modelo: tambm conhecida como camada de domnio, ela a camada onde est
o banco de dados e responsvel por armazenar o status do sistema. Esta camada quem
modela o problema a ser resolvido.
3. View Viso Gerencia a interface de comunicao com o usurio. Esta camada a
responsvel por entregar os dados para visualizao do usurio e receber as entradas do
usurio atravs de mouse e teclado.
Este modelo adequa-se muito bem ao projeto China telecom pois ao separar a lgica
de negcios da apresentao facilitara a empresa a lidar com as diferenas regionais de
linguagem nos diversos pases em que atua.
Alm disso este modelo permitir que a China Telecom utilizar na camada de Visao
um modelo de Web Services, facilitando imensamente a atualizao e controle de variaes
regionais que sejam necessrias, uma vez que ela poder ter vrios Web services regionais
e atualiza-los de forma independente.
Com relao aos frameworks para desenvolvimento o modelo MVC possibilita a
utilizao de diferentes modelos de frameworks para cada camada. Desta forma a empresa
ganharia agilidade no desenvolvimento do sistema acarretando em uma possvel reduo de
custos.
Sugerimos aqui a utilizao do JSF por ser um framework em grande evoluo e que
vem ganhando espao no mercado e por oferecer uma maior flexibilidade e controle no
tratamento de eventos, sem necessidade de utilizar formulrios ou uma Classe Action,
simplificando o desenvolvimento.
Para a persistncia dos dados sugerimos a utilizao de bancos de dados padro
SQL, devido a devido ao baixo custo e facilidade de implantao e administrao alm disso
e compatvel com o framework framework Hibernate, um framework desenvolvido em Java
que oferece suporte para o mapeamento objeto-relacional e oferece uma grande agilidade
no desenvolvimento do sistema e na interao com a camada controle.
Se comparado com a codificao manual e SQL, o Hibernate capaz de diminuir 95% das
tarefas relacionadas a persistncia.

46
A utilizao de cdigo SQL dentro de uma aplicao agrava o problema da independncia
de plataforma de banco de dados e complica, em muito, o trabalho de mapeamento entre
classes e banco de dados relacional e com seus mecanismos de busca permite uma
reduo considervel no tempo de desenvolvimento da aplicao.
O conjunto SQL e Hibernate oferecera a companhia uma grande ajuda e facilidade
no desenvolvimento da aplicao.
Analisando os mtodos de criao e o problema apresentado utilizaremos o padro
de Criao Builder. Pois como indica o problema a empresa e seus produtos se estendem
por mais de 50 pases, cada um com particularidades regionais. Desta forma, utilizando o
padro Builder poderemos dividir os objetos da empresa (produtos) em objetos menores e
mais simples que seriam personalizados com os builder regionais atendendo assim as
necessidades de cada local. Isso seria feito na camada controle de nosso padro MVC,
facilitando assim tambm a manuteno do sistema.
Para elaborao dos artefatos de UML na fase de projetos utilizaramos a ferramenta em

Umbrello pois possui uma interface limpa e consistente e permite a manipulao de todos
os tipos de diagramas UML. Alm disso ele permite importar C++, Pascal, Java entre
outras linguagens e exportar para vrias linguagens tambm. Seu formato padro de
arquivo o baseado em XML
Para elaborao dos artefatos de banco de dados sugerimos o DBDesigner , um editor
visual para criao de banco de dados mySQL que integra criao, modelagem,
desenvolvimento e manuteno dos bancos em um ambiente simples e agradvel.
Distribudo sobre a licena GPL que multiplataforma. Alm disso ele permite engenharia
reversa gerando o modelo a partir de tabelas do BD se necessria e alm disso fornece
suporte a diversos tipos de Bancos de dados como MS SQL, Oracle, e SQ Lite. Esta
ferramenta tem uma tima interface com o usurio sendo simples de usar e salva arquivos
em XML aumentando sua portabilidade. Ele tambm pode gerar documentos em HTML
O DBDesginer tambm pode ser expandido atravs do uso de plug-ins e possui uma
excelente documentao.

47

Concluso
Atravs deste trabalho fizemos um estudo sobre conceitos de gerenciamento de
riscos, gerenciamento de fornecedores e de escopo no desenvolvimento de um plano de
gerenciamento de projetos segundo as normas PMBOK.
Tambm melhoramos as competncias necessrias para o projeto de engenharia de
softwares atravs dos estudos sobre projetos e arquiteturas de software com o livro
Engenharia de Software de Ian Sommerville e para o desenvolvimento de softwares atrevs
de uma pesquisa sobre frameworks web e suas aplicaes.

48

REFERNCIAS BIBLIOGRAFICAS
ANTONIO , Erick Aceiro, FERRO, Milene. Anlise comparativa entre os principais
frameworks de desenvolvimento Java. Congresso Nacional de Ambientes Hipermdia para
Aprendizagem; 5 a 7 Novembro de 2009; Florianpolis; Brasil,
BRIZENO, Marcos. Mo na massa: Factory Method. Disponvel em: 24 Setembro 2011.
Acessado

em

25-04-2015.

https://brizeno.wordpress.com/category/padroes-de-

projeto/factory-method/
DELFIM, Martins Samuel JSF versus STRUTS. Portal do arquiteto. Atualizado em 06
Outubro 2008. acessado em 09-05-2015 disponvel : http://www.portalarquiteto.com.br/jsfversus-struts/
MACORATTI, Jos Carlos. Padres de projeto: o modelo MVC Model View Controller.
Acessado em 30-04-2015 disponvel em : http://www.macoratti.net/vbn_mvc.htm
MEDEIROS, Igor. Introduo ao padro MVC. DEVMEDIA.

Acessado em 28-04-2015.

Disponvel em: http://www.devmedia.com.br/introducao-ao-padrao-mvc/29308

SOMMERVILE, Ian. ENGENHARIA DE SOFTWARE. 8 Edio. So Paulo: Pearson Addison
Wesley, 2007.
SOUZA, Francisco. Uso de frameworks para desenvolvimento web e mitos que j deveriam
ter desaparecido. Disponvel em 21 janeiro de 2010. Acessado em 20-04-2015 Disponvel
em:

http://www.profissionaisti.com.br/2010/01/uso-de-frameworks-para-desenvolvimento-

web-e-mitos-que-ja-deveriam-ter-desaparecido/
Vantagens e desvantagens no uso de frameworks. Acessado em 05-05-2015. Disponvel
em: http://www.dsc.ufcg.edu.br/~jacques/cursos/map/html/frame/porque.htm
Web Services. Construindo, disponibilizando e acessando Web Services via J2SE e J2ME.
Disponivel

em

09

de

Abril

de

2009.

Acessado:

em

05-05-

2015.http://javafree.uol.com.br/topic-871485-Web-Services-Construindo-disponibilizando-eacessando-Web-Services-via-J2SE-e-J2ME.html