49

Sistema de Ensino Presencial ConectadoSuperior de tecnologia em analise e desenvolvimento de sistemas

ricardo mercadante drews

Portflio individual4 Semestre

Londrina2015

ricardo mercadante drews

Portflio individual4 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.Marcio Roberto ChiaveliLus Claudio PeriniMarco Ikuro HisatomiVeronice de Freitas

Londrina2015

1

SumrioSumarioSumario3Introduo5Objetivos6DESAFIO 175 Gerenciamento do escopo do projeto75.1 Planejamento do escopo75.2 Definio do escopo85.3 Criar EAP95.4 Verificao do escopo105.5 Controle do escopo1011 - Gerenciamento de Riscos1211.1 Planejamento de gerenciamento de riscos1211.2 Identificao dos riscos1311.3 Anlise qualitativa de riscos1411.5 Planejamento de resposta a riscos1611.6 Monitoramento de riscos1712 - Gerenciamento de aquisies do projeto1812.1Planejar compras e aquisies1812.2 Planejar contrataes2012.3 Solicitar respostas dos fornecedores2012.4 Selecionar fornecedores2112.5 Administrao de contrato2212.6 Encerramento do contrato23DESAFIO 022411 Projeto de Arquitetura2411.1 Decises de projeto de arquitetura2411.2 Organizao de sistema2511.3 Estilos de decomposio modular2611.4 Modelos de controle2711.5 Arquiteturas de referncia2912 - Arquiteturas de Sistemas Distribudos3012.1 Arquitetura de multiprocessadores3112.2 Arquitetura cliente-servidor3112.3 Arquiteturas de objetos distribudos3212.4 Computao interorganizacional distribuda3313 Arquitetura de aplicaes3613.1 Sistemas de processamento de dados3613.2 Sistema de processamento de transaes.3713.3 Sistemas de processamento de eventos3813.4 Sistema de processamento de linguagens3829 Gerenciamento de configuraes3929.1 Planejamento de gerenciamento de configuraes3929.2 Gerenciamento de mudanas4029.3 Gerenciamento de verses e releases4129.4 Construo de sistemas.4229.5 Ferramentas CASE para gerenciamento de configuraes42DESAFIO 344Desafio 3.144Desafio 3.245Desafio 3.346DESAFIO 447Concluso49REFERNCIAS BIBLIOGRAFICAS50

IntroduoNeste 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 PMBOKEm 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 elesPor fim, faremos um estudo hipottico sobre o estudo de casa da China Telecom, analisando alguns aspectos do projeto China Telecom.

ObjetivosEste 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 riscosTambm buscamos desenvolver habilidade na rea de desenvolvimento de software com estudos de frameworks e analises de modelos de projetos de softwares

DESAFIO 15 Gerenciamento do escopo do projetoO 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 escopoA 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 projetoPara 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 NormasCom 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 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 escopoA 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 aprovadasA definio do escopo utiliza as seguintes ferramentas e tcnicas para o seu desenvolvimento. Analise de produtos Identificao de alternativas Opinio especializada Analise das parte interessadasA 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 aprovao5.3 Criar EAPA 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 aprovadasAs 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 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 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 escopoA 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.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 escopoO 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 trabalhoCom 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 - Gerenciamento de RiscosO 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 riscosNesta 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

11.2 Identificao dos riscosO 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: 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 influnciaCom 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.

11.3 Anlise qualitativa de riscosA 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

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 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 projetoEssas 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

11.5 Planejamento de resposta a riscosA 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.

11.6 Monitoramento de riscosO 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 ameaasEssas 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 projetoO gerenciamento de aquisio do projeto e responsvel pelos processos para comprar ou adquirir produtos, servios ou resultados necessrios de fora da equipe do 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 aquisiesAqui 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.

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

12.2 Planejar contrataesO 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 especializadaA 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 fornecedoresO 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

12.4 Selecionar fornecedoresOs 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 propostasEssas 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 contratoA 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 fornecedorA 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.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 contratoDa suporte ao processo de encerrar um contrato pelo fim do seu projeto ou pela resciso antecipada do mesmo.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 futurasA 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 contratoO 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 registrosEssas ferramentas geram as seguintes contribuies no plano de gerenciamento de projeto: Contratos encerrados Ativos de processos organizacionais: Arquivos de contrato Aceitao de entrega Documentao das lies aprendidasDESAFIO 0211 Projeto de ArquiteturaProjetos 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 vezes exigir que se aplique mais de um modelo de arquitetura para se conseguir uma soluo adequada.

11.1 Decises de projeto de arquiteturaDefinir 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 sistemaO 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 repositrioOs 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-servidorNeste 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 camadasNeste 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 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 modularAps escolher a organizao geral do sistemas iremos decidir sobre a abordagem que usaremos nos mdulos do sistema. Aqui podemos utilizar os mesmos estilosexplicados 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 funesNeste modelo os dados so enviados de uma funo para outra e transformados at serem convertidos em uma sada. Essas transformaes podem ocorrer de forma 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 controleOs 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 centralizadoNeste modelo um subsistema tem a responsabilidade pelo gerenciamento e execuo de todos os outros. Esse modelo divide-se em duas classes1 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 eventosNeste 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.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 refernciaOs 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.

12 - Arquiteturas de Sistemas DistribudosOs 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 combinados3. Concorrncia, permitindo vrios processos simultneos em diferentes computadores4. 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 intra-organizacional.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

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-servidorNeste 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, do uso de diversos bancos de dados e compatibilidade entre diferentes sistemas para o processamento dos dados.

12.3 Arquiteturas de objetos distribudosNeste 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:1- Permite ao projetista postergar decises sobre onde e como servios sero oferecidos.2- Facilita a incluso de novos recursos desde que este se comunique com o middleware.3- Torna o sistema mais flexvel pois os objetos podem ser independentes entre si.4- 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 CORBACORBA 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 dadosUm 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 distribudaInicialmente 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 pontoNesta 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.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 servioO 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 UML1. SOAP (Simple Object Acess Protocol) que define uma organizao para troca de dados.2. WSDL (web Services Description Language) Que define a apresentao das interfaces3. 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.

13 Arquitetura de aplicaesNegcios 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 dadosEsses 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.

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. Um banco de dados que mantem detalhes sobre os recursos alocados, 2. Um conjunto de regras para alocao de recursos.3. Um componente de gerenciamento de recursos4. Um componente de alocao de recursos5. Um modulo de autenticao de usurios6. Um modulo de gerenciamento de consultas7. Um componente de entrega de recursos8. 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.

13.3 Sistemas de processamento de eventosSistemas 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 linguagensSo 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. Analisador lxico que verifica a validade das palavras2. Tabela de smbolos validos para a linguagem3. Analisador sinttico quer verifica a validade da linguagem sendo traduzida4. Uma arvore de sintaxe que representa o programa a ser compilado5. Um analisador semntico faz correo sinttica do texto de entrada6. Gerador de cdigo que gera a linguagem de mquina abstrata

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 configuraesO 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 configuraoNo 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. 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 configuraoUm 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. Quais clientes pegaram uma verso especifica do produto2. Qual a verso para um determinado tipo de hardware3. Quantas verses o sistema possui4. Quais verses sero afetadas pela alterao em um componente5. Quantas solicitaes de alterao esto pendentes para determinada verso do sistema6. 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 mudanasDevido 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. 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 releasesUm 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 versesA verso de um sistema especifica quais so as verses dos componentes includas nela. Essa identificao deve ser feita de maneira no ambguaTrs 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 releasesRelease 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, 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 configuraesUso 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 mudanasCom 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.29.5.2 Apoio para o gerenciamento de versesO 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. Identificao das verses e releases2. Gerenciamento de armazenamento das diversas verses3. Registro do histrico de mudanas4. 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 sistemasEssas 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 associado1. Seleo de ferramenta e apoio instanciao2. Compilao distribuda3. Gerenciamento de objetos derivados

DESAFIO 3

Desafio 3.1JSF (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 JSPStruts 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 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.2Frameworks 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 frameworks que exigem pouca ou nenhuma configurao especial. Portanto a vantagem ou desvantagem vai depender de usar a ferramenta adequada ao projeto.

Desafio 3.3Para 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.

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 modelo2. 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. 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 XMLPara 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.

ConclusoAtravs 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.

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/jsf-versus-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-e-acessando-Web-Services-via-J2SE-e-J2ME.html