unopar locadora de video

Upload: izaias-da-silva

Post on 07-Mar-2016

244 views

Category:

Documents


0 download

DESCRIPTION

trabalho Unopar Locadora de video do 1 semestre

TRANSCRIPT

ABNT - UNOPAR - Completo

PAGE

SUMRIO31 INTRODUO............................................................................................................

42 OBJETIVOS................................................................................................................

42.1 Geral.........................................................................................................................

42.1.1 Especificos............................................................................................................

53 ENGENHARIA E PROJETO DE SOFTWARE..............................................................

53.1. Engenharia e Projeto de Software - Proposta de projeto (desafio 1) ...................

53.1.2 Engenharia e Projeto de Software - projeto gerencivel baseado no PMBoK (desafio 2) ......................................................................................................................

63.2 PROGRAMAO PARA WEB II Desafio 3.............................................................

63.3 PROJETO ORIENTADO A OBJETOS Desafio 4..................................................

74 CONCLUSO.............................................................................................................

75 REFERNCIAS...........................................................................................................

1 INTRODUOEste trabalho visa apresentar um pouco sobre a Engenharia e Projeto de Software como meio para promover o desenvolvimento de aplicativos para os diversos usos corporativos e institucionais e suas implicaes no desenvolvimento de projetos focando no gerenciamento por meio da ferramenta PMBOK. Tambm ser abordada a programao voltada para Web II, com uso de framework para linguagem Java. Cabe ressaltar que a engenharia de software e o gerenciamento de projetos so elementos indispensveis no bom desenvolvimento de aplicativos e manuteno dos existentes, que em alguns casos podem vir a ser substituidos por outros ou ter sua vida prolongada devido ao seu grande valor para a empresa possuidora. 2 Objetivos2.1 geral Analisar o ambiente da empresa China Telecom propondo uma abordagem com foco nas tecnologias mais recentes na area de gesto de projetos e programo Web.2.1.1 ESPECFICOS Criar um modelo de projeto utilizando a ferramenta PMBOK. Propor a utilizao de tecnologia framework para Java na programao para Web.

Criar diagramas de um projeto orientado a Objetos. 3 ENGENHARIA E PROJETO DE SOFTWARE A Engenharia de Software uma disciplina de engenharia relacionada a produo de software. De acordo Perine (2009) a engenharia de Software est relacionada com todos os apectos da produo de um software, desde estgios iniciais de especificao do sistema at sua manuteno, depois que entra em operao. 3.1 ENGENHARIA E PROJETO DE SOFTWARE - Proposta de projeto (Desafio 1)A empresa CHINA TELECOM necessita de um Projeto de software que contenha as seguintes especificaes (baseado no livro de Ian Summerville - Engenharia de Software): Projeto de Arquitetura

Sistemas amplos so constitudos de subsistemas que fornecem servios que inter-relacionam entre si. O projeto de arquitetura o processo no inicio do projeto que identifica esses subsistemas e constitui um framework que identifica os principais componentes para controle e comunicao. A comunicao de stakeholdes para analise do planejamento do projeto, a estrutura do sistema especifica, e o reuso so vantagens de projetar um software documentado. A arquitetura do sistema uma ferramenta essencial parra gerenciamento de complexidade, ocultando detalhes e focando as abstraes principais do sistema, estando relacionada com o estilo e a estrutura de uma aplicao e dependem de requisitos no funcionais como: desempenho, proteo, segurana, disponibilidade, manunteo. Mas pode haver conflitos potenciais entre algumas dessas arquiteturas, por exemplo, se o desempenho que necessita de alta granularidade e a facilidade de manuteno que necessita de baixa granularidade forem ambos os requisitos crticos ter que ser encontrada alguma soluo eficaz. Um projeto de subsistemas decomposio abstrata de um sistema de componentes em alta granularidade. Os diagramas de blocos so usados para representar um projeto de subsistemas e so eficientes na comunicao entre stakeholders e para o planejamento do projeto, pois no esto preenchidos de detalhes, mas na arquitetura no so to eficientes, pois no demonstram os relacionamentos entre os componentes.

Dentre as diversas arquiteturas existentes oi escolhida para o projeto da CHINA TELECOM o modelo MVC (Model View Controller).-.Arquitetura de sistemas distribudos

3.7 Arquitetura de multiprocessadores.

O multiprocessador So processos que podem ser executados separados. Esse modelo tomam decises usando essas informaes e enviam sinais aos atuadores, que modificam o ambiente do sistema. O uso de vrios processadores aprimora o desempenho e a capacidade de recuperao do sistema.

3.8 Arquitetura cliente-servidor.

Em uma arquitetura cliente-servidor, uma aplicao modelada como um conjunto de clientes que usam esses servios. Os clientes precisam estar informados sobre os servios disponveis, mas geralmente no sabem da existncia de outros clientes. Vrios processos de servios podem ser executados em um nico processador de servio portanto no h mapeamento entre processos e processadores de um sistema. O projeto de sistemas cliente-servidor deve refletir a estrutura lgica da aplicao que esta sendo desenvolvida. Um exemplo uma aplicao q esta dividida em 3 camadas: a camada de apresentao, que se encarrega da apresentao de informaes para o usurio e toda a interao com o usurio. A camada de processos de aplicaes se encarrega da implementao da lgica da aplicao e a camada de gerenciamento de dados se encarrega de todas as operaes de banco de dados. A arquitetura cliente-servidor mais simples denomina-se arquitetura cliente-servidor de duas camadas, podem ter duas formas:

Modelo cliente-magro. O processamento e o gerenciamento de dados so realizados no servidor. O cliente apenas executa o software de apresentao.

Modelo cliente-gordo. O servidor responsvel somente pelo gerenciamento de dados. O software do cliente implementa a lgica da aplicao e as interaes com o usurio do sistema.

Uma desvantagem do modelo cliente-magro que ele impe uma grande carga de processamento sobre o servidor e a rede. O modelo cliente-gordo faz uso dessa capacidade de processamento disponvel e distribui o processamento lgico de aplicao e a apresentao do cliente. O servidor essencialmente um servidor de transaes que gerencia todas as transaes do banco de dados. Enquanto o modelo cliente-gordo distribui o processamento mais eficientemente do que um modelo cliente-magro, o gerenciamento do sistema mais complexo. A funcionalidade da aplicao dividida entre vrios computadores. Quando o software precisa ser alterado, isso envolve reinstalao em cada computador cliente, o que pode resultar em um custo significativo se houver centenas de clientes no sistema. O Problema com a abordagem cliente-servidor de duas camadas que as trs camadas lgicas, devem ser mapeadas sobre dois sistemas de computador o cliente e o servidor. Pode haver problemas de escalabilidade e desempenho, se o modelo cliente-magro for escolhido, ou problemas de gerenciamento de sistemas, se o modelo cliente-gordo for usado. Para evitar esses problemas uma alternativa usar o modelo cliente-servidor de trs camadas. Em alguns casos melhor estender o modelo cliente-servidor de trs camadas para uma variante com varias camadas, na qual servidores adicionais so incorporados ao sistema.

3.9 Arquiteturas de objetos distribudos.

Nesse modelo os objetos podem ser distribudos entre uma serie de computadores na rede e se comunicam atravs de um middleware, que chamado de requisitor de objetos. O Middleware fornece uma interface transparente continua entre os objetos. Ele fornece um conjunto de servios que permitem que os objetos se comuniquem e sejam adicionados e removidos do sistema. As vantagens so:

Permite que o projetista do sistema postergue decises sobre onde e como os servios devem ser fornecidos.

uma arquitetura de sistema aberto que permite que novos recursos sejam adicionados.

Uma arquitetura de objetos distribudos pode ser usada como um modelo lgico, que permite estruturar e organizar o sistema.

3.10 Corba.

O Corba considera um objeto como se fosse um encapsulamento de atributos e servios, como normal em objetos. O Corba deve ter uma definio de interface separada que define atributos e operaes publicas do objeto. as interfaces so definidas por uma linguagem de definio de interface padronizada independe de linguagem. Os objetos corba tem um nico identificador chamado de referencia de objeto interoperavel. Esse IOR usado quando um objeto solicita servios de um outro objeto. O requisitor de objetos conhece os objetos que esto solicitando servios e suas interfaces. O ORB cuida da comunicao entre os objetos.os objetos que se comunicam no precisam conhecer a localizao de outros objetos nem sobre sua implementao. O objeto que fornece o servio tem um esqueleto de IDL associado que liga a interface a implementao dos servios. O corba foi desenvolvido desde 1980 e as verses recentes de corba foram simplesmente dedicadas ao apoio aos objetos distribudos.

Os padres Corba incluem definies de interface para uma grande variedade de componentes horizontais e verticais. Os componentes verticais so componentes especficos de um domnio de aplicao. Os componentes horizontais so componente de propsito geral, como componentes de interface com o usurio.

3.11 Computao interorganizacional distribuda.

Por motivo de segurana e interoperabilidade, a computao distribuda foi implementada inicialmente em nvel organizacional. Uma organizao tem uma serie de servidores e distribui sua carga computacional entre eles. Devido ao fato de eles estarem todos localizados dentro da mesma organizao, podem ser aplicados padres e processos operacionais locais.

3.11.1 Arquiteturas ponto a ponto.

So sistemas descentralizados em que as computaes podem ser realizadas por qualquer n da rede, nenhuma distino feita entre clientes e servidores. O sistema global projetado para beneficiar-se da capacidade computacional e armazenamento disponvel em uma rede de computadores potencialmente grande. Em principio, em sistemas ponto a ponto, todo n de rede pode estar ciente a respeito de qualquer outro n, pode fazer conexes com ele e pode trocar dados com ele. Em uma arquitetura descentralizada, os nos de rede no so simplesmente elementos funcionais, mais tambm chaves de comunicao que podem guiar os sinais de dados e de controle de um n para o outro. No entanto quando se recupera um documento, o n que esta recuperando se torna visvel para outros.

3.11.2 Arquitetura de sistema orientada a servios.

A essncia de um servio, que o fornecimento dos servios independente da aplicao que usa o servio. Os provedores de servios podem desenvolver servios especializados e oferec-los a uma gama de usurios de servios de organizaes diferentes. A proposto WEB Service foi lanada pois o acesso de servidores web, era somente por meio de navegar web, e o acesso direto aos repositrios de informaes por outros programas no era pratico. Os trs padres fundamentais, baseados em XML, possibilitam comunicao entre WEB SERVICES so:

SOP. Define uma organizao para troca estruturada de dados entre WEB SERVICES.

WSDL. Define como as interfaces dos WEB services podem ser representadas.

UDDI. Este um padro de descobrimento que define como as informaes de descrio do servio usadas pelos solicitantes do servios para descobrir servios, pode ser organizada.

- Arquitetura de aplicaes.3.12 Sistemas de processamento de dados.

So aplicaes voltados a dados. Elas Processam dados em lotes sem intervenes explicitas do usurio durante o processamento. As Aes explicitas tomadas pela aplicao dependem dos dados que so processados. Os sistemas de processamento em lotes so normalmente usados em aplicaes de negcios nas quais as operaes similares so realizadas sobre uma grande quantidade de dados. Eles tratam de uma grande variedade de funes administrativas, como folha de pagamento, cobrana, contabilidade e publicidade. Essas aplicaes enfocam os dados. Os bancos de dados so geralmente maiores que os sistemas de informaes (SI). Os sistemas de processamento de dados selecionam os dados de registros de entrada e, dependendo do valor dos campos nos registros, tomam algumas aes especificadas no programa. Eles podem, ento, enviar o resultado novamente do processamento ao banco de dados e formatar a entrada e a sada processada para impresso. Os sistemas de processamento de dados possuem 3 componentes principais:

1. Entrada. A entrada coleta as entradas de uma ou mais fontes.

2. Processamento. O processamento realiza a computao usando essas entradas.

3. Sada. A sada gera Sadas a serem escritas novamente no banco de dados e ou impressas.

Os componentes de entrada , processamento e de sada podem ser decompostos ainda em uma estrutura entrada-processamento-sada. Exemplo: Um componente de entrada pode ler algum dado de um arquivo ou banco de dados(entrada) e corrigir alguns erros (processo) e, depois enfileirar os dados validos para processamento (sada).

So sistemas orientados a funes, pois os registros e as transaes so processados em serie, sem necessidade de manter o estado entre as transaes.

3.13 Sistemas de processamento de transaes.

Os sistemas de transaes so projetados para processar solicitaes de informaes por usurios de um banco de dados. Tecnicamente uma sequencia de operaes tratada como uma unidade simples (uma unidade atmica). Todas as operaes tem que ser realizadas antes que as mudanas tornem-se permanentes no banco de dados. Os sistemas de processamento de transaes so geralmente sistemas interativos nos quais os usurios enviam solicitaes assncronas de servio. Primeiro um usurio faz uma solicitao para o sistema atravs de um componente de processamento de entrada/sada. A solicitao processada por alguma lgica especifica da aplicao. Uma transao criada e passada para um gerenciador de transaes, que em geral incorporado ao sistema de gerenciamento de banco de dados. Depois que o gerenciador de transaes assegurarem que a transao foi concluda adequadamente, ele sinalizara para a aplicao que o processamento foi finalizado. A estrutura entrada-processo-sada se aplica aos muitos sistemas de processamento de transaes. Alguns desses sistemas so verses interativas de sistemas de processamento de lotes. Um exemplo de sistema de processamento de transaes um sistema bancrio que permite aos clientes consultarem suas contas e retirarem dinheiro de um caixa eletrnico. O sistema composto de dois subsistemas de software que cooperam entre si o software de caixa eletrnico e o software de processamento de contas localizadas no servidor de banco de dados.

Os subsistemas de entrada e de sada so implementados como softwares no caixa eletrnico, uma vez que o subsistema de processamento est no servidor de banco de dado. Em sistemas como os de contabilidade de clientes de um banco, pode haver diferentes maneiras de interagir com o sistema. Muitos clientes interagiro por meio de caixas eletrnicos, mas uma equipe do banco usara terminais de mesa para acessar o sistema. Pode haver vrios tipos de caixas eletrnicos e terminais de mesa, e alguns clientes e a equipe do banco podem acessar os dados de contas por meio de navegadores WEB. Para simplificar o gerenciamento de diferentes protocolos de comunicao entre terminais, sistemas de processamento de transaes de larga escala podem incluir middleware para comunicao com todos os tipos de terminal, organizao e ordenao em serie dos dados dos terminais e envio dos dados para processamento.

3.13.1 Sistemas de gerenciamento de informaes e recursos.

Um sistema de informaes permite acesso controlado de uma grande base de informaes, tais como catalogo de bibliotecas, tabela de horrios de voos ou registros de pacientes em um hospital. O desenvolvimento da WEB fez com que um grande numero de sistemas de informaes migrasse de sistemas organizacionais especializados para sistemas de propsito geral acessveis universalmente. O sistema de informao modelado com o uso de uma abordagem de camadas ou de maquina abstrata na qual a camada superior apoia a interface com o usurio e a camada inferior, o banco de dados de sistema. A camada de comunicaes inclui uma lgica especifica de aplicao para acesso e atualizao do banco de dados. Sistemas de alocao de recursos uma classe de aplicao amplamente usada. Sua arquitetura esta alinhada com o modelo de sistema de informaes. Os componentes de um sistema de alocao de recursos incluem:

Um banco de dados de recursos que mantm detalhes de recursos que so alocados. Os recursos podem ser adicionados ou removidos do banco de dados.

Um conjunto de regras que descreve as regras de alocao de recursos.

Um componente de gerenciamento de recursos que permite que o provedor de recursos adicione, edite ou elimine recursos do sistema.

Um componente de alocao de recursos que atualiza o banco de dados de recursos quando eles so designados e que associa esse recursos a detalhes do solicitante do recurso.

Um modulo de autenticao de usurios que permite ao sistema verificar se os recursos esto sendo alocados para um usurio reconhecido.

Um modulo de gerenciamento de consultas que permite ao usurio descobrir quais recursos esto disponveis.

Um componente de entrega de recursos que prepara os recursos a serem entregues ao solicitante. Em um sistema de emisso de ingressos, isso pode envolver a preparao de uma confirmao por e-mail, o envio de uma solicitao para uma impressora que imprime os ingressos e os detalhes de para onde os ingressos devem ser enviados.

Um componente de interface com o usurio que esta fora do sistema e permite ao solicitante do recurso enviar consultas e solicitaes para o recurso a ser alocado.

3.14 Sistemas de processamento de eventos.

Os sistemas de processamento de eventos respondem aos eventos do ambiente ou da interface com o usurio do sistema. A principal caracterstica dos sistemas de processamento de eventos que a sequencia de eventos imprevisvel e o sistema deve ser capaz de trabalhar com esses eventos quando eles ocorrerem. Sistemas de tempo real so tambm sistemas de processamento baseados em eventos, porem ao invs de ter eventos de interface com o usurio, tem eventos associados a sensores e atuadores do sistema.

3.15 Sistemas de processamento de linguagens.

Os sistemas de processamento de linguagens aceitam uma linguagem natural ou artificial como entrada e geram alguma outra representao dessa linguagem como sada. Em engenharia de software, os sistemas de processamento de linguagens mais amplamente usados so os compiladores que traduzem uma linguagem artificial de programao de alto nvel em cdigo de maquina. Mais outros sistemas de processamento de linguagens traduzem uma descrio de dados XML em comandos para consultar um banco de dados e sistemas de processamento de linguagem natural que tentam traduzir uma linguagem em outra. Os tradutores em um sistema de processamento de linguagens tem uma arquitetura genrica que inclui os seguintes componentes:

Um analisador lxico, que obtm elementos da linguagem de entrada e os converte em um formato interno.

Uma tabela de smbolos que mantm informaes sobre os nomes de entidades (variveis, nomes de classes.) usadas no texto que esta sendo traduzido.

Um analisador sinttico, que verifica a sintaxe da linguagem que est sendo traduzida. Ele usa uma gramtica definida de linguagem e constri uma arvore de sintaxe.

Uma rvore de sintaxe, que uma estrutura interna que representa o programa que esta sendo compilado.

Um analisador semntico, que usa informaes da rvore de sintaxe e da tabela de smbolos para verificar a correo sinttica do texto da linguagem de entrada.

Um gerador de cdigo que caminha pela rvore de sintaxe e gera o cdigo de maquina abstrata.

3.16 Gerenciamento de Configuraes.

Gerenciamento de configuraes o desenvolvimento e o uso de padres e procedimentos para o gerenciamento de sistemas de software em desenvolvimento.Ha muitas razes Por que os sistemas existem em diferentes configuraes. Configuraes podem ser produzidas para diferentes computadores, para diferentes sistemas operacionais, incorporando funes especificas de clientes. Os gerentes de configuraes so responsveis por manter a rastreabilidade das diferenas entre verses de software, para assegurar que as novas verses sejam derivadas de maneira controlada e liberar novas verses para clientes certos no momento certo.

- Gerenciamento de Configurao.3.17 Planejamento de gerenciamento de configuraes.

O plano de gerenciamento de configuraes descreve os padres e procedimentos que devem ser usados para o gerenciamento. O ponto de partida para o desenvolvimento do plano deve ser um conjunto de padres de configurao, que devem ser adaptados para se atender aos requisitos e as restries de cada projeto especfico.

3.17.1 Identificao de item de configurao.

Em um grande sistema de software, pode haver mdulos de milhares de cdigos fonte, scripts de testes, documentos de projeto etc. Eles so produzidos por pessoas diferentes e, quando criados, podem ser denominados com nomes similares ou idnticos. Para manter a rastreabilidade de todas essas informaes de maneira que o arquivo certo possa ser encontrado quando for necessrio voc necessita de um esquema de identificao consistente para todos os itens no sistema de gerenciamento de configuraes. Durante o processo de planejamento de gerenciamento de configurao, voc decide exatamente quais itens sero controlados. Planos de projetos, especificaes, projetos, programas, e massa de dados de teste so normalmente mantidos como itens de configurao. Todos os documentos que podem ser uteis para a evoluo futura do sistema devem ser controlados pelo sistema de gerenciamento de configurao. O esquema de identificao de itens de configurao deve atribuir um nico nome para todos os documentos sob controle de configurao. Esse nome pode refletir o tipo do item, uma parte do sistema ao qual ele se aplica o criador do item. No esquema de atribuio de nomes, voc pode desejar evidenciar a relao entre os itens para garantir que os documentos relacionados possuam uma mesma raiz em seus nomes. Portanto, voc pode definir um esquema de hierarquia com nome. Esquemas de nomes hierarquizados so simples e de fcil compreenso: algumas vezes, podem mapear uma estrutura de diretrios usada para armazenar arquivos de projeto. No entanto, refletem a estrutura de projeto na qual o software foi desenvolvido. Os nomes de itens de configurao associam componentes com um projeto especifico e, dessa maneira, reduzem as oportunidades para o reuso. Pode ser muito difcil encontrar componentes relacionados.

3.17.2 Banco de dados de configurao.

O banco de dados de configurao utilizado para registrar todas as informaes relevantes sobre as configuraes de sistema e os itens de configurao. Voc usa o banco de dados CM para auxiliar a avaliao do impacto das mudanas de sistema e para gerar relatrios para a gerencia sobre o processo de CM. Como parte do processo de CM, deve-se definir o esquema do banco de dados de CM, os formulrios para coletar informaes para serem registradas no banco de dados e procedimentos para registro e recuperao de informaes de projeto. Um banco de dados de configurao pode registrar informaes sobre usurios de componentes, clientes de sistemas, plataformas de execuo, mudanas propostas e etc. De preferncia, um banco de dados de configurao deve ser integrado com a verso do sistema de gerenciamento usada para armazenar e gerenciar os documentos formais do projeto. Um banco de dados de configurao armazena informaes sobre itens de configurao e referencia seus nomes num sistema de gerenciamento de verso ou depsito de arquivos.

3.18 Gerenciamento de mudanas.

As necessidades e requisitos organizacionais alteram-se durante a vida til de um sistema. Isso significa que voc precisa fazer as mudanas correspondentes no sistema de software. Para garantir que essas mudanas sero aplicadas ao sistema de maneira controlada, voc precisa de um conjunto de procedimentos de gerenciamento de mudanas apoiado por ferramentas. Procedimentos de gerenciamento de mudana dizem respeito a analise de custo e beneficio das mudanas propostas, a aprovao das mudanas viveis e a rastreabilidade de quais componentes do sistema foram alterados. O processo de gerenciamento de mudana deve surtir efeito quando o software ou a documentao associada so colocados em baseline pela equipe de gerenciamento de configuraes.

O primeiro estgio no processo de gerenciamento de configuraes completar um formulrio de solicitao de mudana (CRF change request form) que descreve a mudana necessria para o sistema. Uma vez que o formulrio de solicitao de mudana enviado, ele deve ser registrado no banco de dados de configurao. A solicitao de mudana ento analisada para verificar se a mudana solicitada necessria. Para mudanas validas, o estagio seguinte a avaliao da mudana e o custo. O impacto da mudana no restante do sistema deve ser verificado. Isso envolve todos os componentes afetados pela mudana. Se realizar a mudana significa que mudanas adicionais em alguma parte do sistema so necessrias, isso aumenta claramente o custo de sua implementao. Em seguida as mudanas necessrias para os mdulos do sistema so avaliadas. Finalmente, o custo para realizar a mudana estimado, considerando os custos de mudana nos componentes relacionados.

3.19 Gerenciamento de verses e releases.

Os processos envolvidos no gerenciamento de verses e relases preocupam-se com a identificao e a manuteno da rastreabilidade das verses de um sistema. Gerentes de verses idealizam procedimentos para assegurar que as verses de um sistema possam ser recuperadas quando solicitadas e no sejam alteradas acidentalmente pela equipe de desenvolvimento. Para produtos, os gerentes trabalham com a equipe de marketing, e , para sistemas feitos sob encomenda, com os clientes, para planejar quando novos releases de um sistema devem ser criados e distribudos para implantao. Um release do sistema uma verso distribuda aos clientes. Cada release deve incorporar novas funcionalidades ou ser planejado para uma plataforma diferente de hardware.

3.19.1 Identificao de verses.

Para criar uma verso especifica de um sistema, voc precisa especificar as verses dos componentes de sistema que devem ser includas nele. Voc no pode usar o nome do item de configurao para identificar a verso, porque ele pode ter muitas verses para cada item de configurao identificado. A trs tcnicas bsicas para identificao da verso de componentes.

1. Numerao de verses. O componente recebe um numero explicito e nico de verso. Isso o mais comumente usado no esquema de identificao.

2. identificao baseada em atributos. Cada componente tem um nome (como o nome do item de configurao, que no nico para diferentes verses) e um grupo de atributos associados para cada verso, componentes so portanto, identificados pela especificao de seus nomes e valores de atributos.

3. identificao orientada a mudanas. Cada componente denominado como na identificao baseada em atributos, mas tambm associado com uma ou mais solicitaes de mudanas. Ou seja, considera se que cada verso de componente foi criada em resposta a uma ou mais solicitaes de mudanas. A verso de componente identificada pelo conjunto de solicitaes de mudanas que se aplicam ao componente.

3.19.2 Gerenciamento de releases.

Um release de sistema uma verso do sistema distribudo para os clientes. Os gerentes de release de sistemas so responsveis por decidir quando um sistema pode ser liberado para os clientes, gerenciar o processo de criao do release e de meios de distribuio e documentar o release para assegurar que ele pode ser recriado exatamente como foi distribudo, se for necessrio. A criao de um release um processo de criao de arquivos e documentos que inclui todos os componentes do release do sistema. O cdigo executvel de programas e todos os arquivos de dados associados devem ser coletados e identificados. Se os manuais a serem lidos em computadores so distribudos, copias eletrnica devem ser armazenadas com o software. Finalmente, quando todas as informaes estiverem disponveis, o diretrio do release manipulado para a distribuio. Quando um release de sistema produzido, ele deve ser documentado para assegurar que possa ser recriado ipsis literis no futuro. Isso importante para sistemas embutidos de ciclo de vida longo e feitos para os clientes, como aqueles que controlam maquinas complexas.

Para documentar um release voc deve registrar as verses especificas dos componentes de cdigo fonte usados para criar o cdigo executvel. Voc deve manter compias dos cdigos fonte e cdigo executvel, e de todos os arquivos de dados e de configurao. Voc deve tambm registrar as verses do sistema operacional, as bibliotecas, os compiladores e outras ferramentas usadas para construir o software. Elas podem ser necessrias para construir exatamente o mesmo sistema em alguma data posterior.

3.20 Construo de sistemas.

A construo de sistemas um processo de compilao e ligao de componentes de software num programa que executa determinada configurao definida. Quando voc esta construindo um sistema com base em seus componentes, voc deve pensar nas seguintes questes:

Todos os componentes que compem um sistema foram includos nas instrues de construo?

A verso apropriada de cada componente necessrio foi includa nas instrues de construo ?

todos os arquivos de dados necessrios esto disponveis?

Se os arquivos de dados esto referenciados dentro de um componente, o nome usado o mesmo que o do arquivo de dados na maquina alvo?

A verso apropriada do compilador e de outras ferramentas requeridas esta disponvel? As verses atuais das ferramentas de software podem ser incompatveis com as verses antigas usadas para desenvolver o sistema.

3.21 Ferramentas CASE para gerenciamento de configuraes.

Processos de gerenciamento de configuraes so normalmente padronizados e envolvem aplicaes de procedimentos predefinidos. Eles requerem o gerenciamento cuidadoso de grande quantidade de dados e essencial a ateno aos detalhes. Quando um sistema est sendo construdo com base em verses de componentes, um nico erro de gerenciamento de configurao pode significar que o software no ir operar adequadamente. Consequentemente, o apoio de um ferramenta CASE essencial para o gerenciamento de configurao. Essas ferramentas podem ser combinadas para criar uma rea de trabalho para apoiar todas as atividades de CM.

3.1.1 ENGENHARIA E PROJETO DE SOFTWARE Desafio 2De acordo com Dvila (2015) Um projeto um esforo temporrio empreendido para criar um produto, servio ou resultado exclusivo. Para a desenvolvimento do softwarte se optou pela seguinte organizao: EAP ESTRUTURA ANALTICA DO PROJETO ndice Analtico

41.Introduo

41.1Finalidade

41.2Escopo

41.3Definies, Acrnimos e Abreviaes

41.4Referncias

51.5Viso Geral

52.Viso Geral do Projeto

52.1Finalidade, Escopo e Objetivos do Projeto

52.2Suposies e Restries

52.3Produtos Liberados do Projeto

52.4Evoluo do Plano de Desenvolvimento de Software

53.Organizao do Projeto

53.1Estrutura Organizacional

63.2Interfaces Externas

63.3Papis e Responsabilidades

74.Processo de Gerenciamento

74.1Estimativas do Projeto

74.2Plano de Projeto

74.2.1Plano de Fase

74.2.2Objetivos das Iteraes

74.2.3Releases

74.2.4Programao do Projeto

74.2.5Recursos do Projeto

74.3Monitoramento e Controle do Projeto

95.Anexos

ARTEFATO

Tudo que produzido e documentado em qualquer atividade de qualquer fluxo do projeto. Por exemplo: documento de requisitos, diagrama de casos de usos e glossrio.

A EAP fundamental para o projeto, pois, fornece uma viso estruturada do que ser entregue facilitando o entendimento das partes interessadas em relao ao que deve ser feito (escopo) no projeto, alm, de servir de base para o planejamento das outras reas de conhecimento.

Entradas, Ferramentas e Sadas do Processo 5.4 Criar a EAP (Guia PMBOK)

O processo de subdiviso das entregas e do trabalho do projeto em componentes menores e mais facilmente gerenciveis. J o principal benefcio desse processo o fornecimento de uma viso estruturada do que deve ser entregue.Os objetivos do desenvolvimento de uma EAP e do Dicionrio da EAP servem

1 Para a equipe do projeto planejar de forma proativa e logicamente o projeto at a concluso.

2 Para coletar as informaes sobre o trabalho que precisa ser feito para um projeto, e

3 Para organizar as atividades em componentes gerenciveis que iro atingir os objetivos do projeto . A EAP e Dicionrio da EAP no so o cronograma , mas os blocos de construo para ele.

- CRONOGRAMA DAS ATIVIDADES PARA O DESENVOLVIMENTO DO PROJETO

Os objetivos da EAP, Dicionrio da EAP e do Cronograma Detalhado so:

A EAP e o Dicionrio da EAP no devem ser documentos estticos. A construo da EAP est sujeita a elaborao progressiva, conforme novas informaes se tornam conhecidas, a EAP deve ser revista para refletir essa informao. A equipe do projeto, que tem alteraes substanciais sua EAP deve fazer referncia ao Plano de Gesto das Mudanas do projeto e seguir a orientao sobre gesto de mudanas no escopo do projeto.

- Relao dos envolvidos, papis dentro do projeto.Todas as pessoas e organizaes envolvidas no projeto, ou cujos interesses podem ser positiva ou negativamente afetados pela realizao ou pelos resultados do projeto, so as partes interessadas e podem exercer influncia sobre o projeto e sobre os membros da equipe do projeto. Desde a iniciao do projeto, a equipe de gerenciamento precisa identificar as partes interessadas internas e externas. Ao longo do planejamento e da execuo do projeto, o gerente do projeto e sua equipe devem gerenciar as diferentes necessidades, preocupaes e expectativas das partes interessadas, bem como a influncia destas no projeto, para garantir um resultado bem sucedido.Alguns exemplos de possveis partes interessadas podem incluir:

Clientes e usurios;

Presidente, donos e executivos;

Acionistas e investidores;

Gerentes funcionais;

Escritrio de projetos (Project Management Office- PMO), gerentes e comits de portflios e de programas;

Fornecedores e parceiros comerciais;

Concorrentes;

Governo, em suas diversas esferas e poderes;

Organismos de regulao e fiscalizao internos e externos, incluindo auditorias, agncias, conselhos, sindicatos e associaes institucionais, profissionais e oficiais;

Organizaes no governamentais (ONG);

Comunidades, vizinhana e populao abrangida pelas aes e resultados do projeto.

Elementos importantes que influenciam projetos so asculturas e estilos organizacionais, osfatores ambientaisda empresa, do mercado, da sociedade e da localizao geopoltica onde o projeto acontece.

3.2 PROGRAMAO PARA WEB II Desafio 31. Para criao do projeto Java Web foi selecionado a IDE Eclipse e foi estruturado assim:

2. 3. Foi criado os seguintes arquivos:

4. portfoliogrupo5 > src > banco > BancoDeClientes.java

5. portfoliogrupo5 > src > banco > HibernateUtil.java

6. portfoliogrupo5 > src > bean > ClienteBean.java

7. portfoliogrupo5 > src > modelo > Cliente.java

8. portfoliogrupo5 > src > hibernate.cfg.xml

9. portfoliogrupo5 > WebContent > tema > template.xhtml

10. portfoliogrupo5 > WebContent > views > cliente.xhtml

11. portfoliogrupo5 > WebContent > WEB-INF> lib > [ colocado as *.jar necessrias aqui ]12. portfoliogrupo5 > WebContent > WEB-INF> faces-config.xml13. portfoliogrupo5 > WebContent > WEB-INF> web.xml

14. portfoliogrupo5 > WebContent > index.html

15. portfoliogrupo5 > WebContent > index.xhtml

16. Arquivo BancoDeClientes.java:

17. package banco;18. import modelo.Cliente;19. import org.hibernate.Session;20. import org.hibernate.Transaction;21. public class BancoDeClientes {22. public String salvar(Cliente u) {23.

Session sessao = null;24.

Transaction tx = null;25.

try {26.

sessao = HibernateUtil.getSession();27.

tx = sessao.beginTransaction();28.

sessao.save(u);29.

tx.commit();

30.

System.out.println("ENTREI =======================> AQUI = COMMIT");31.

} catch (Exception ex) {32.

System.out.println("ENTREI =======================> AQUI = ROLLBACK");33.

tx.rollback();34.

ex.printStackTrace();35.

} finally {36.

if (sessao != null) {37.

try {38.

sessao.close();39.

} catch (Exception e) {40.

e.printStackTrace();41.

}42.

}43.

}44.

return null;45. }46. }47. Arquivo HibernateUtil.java:

48. package banco;49. import org.hibernate.Session;50. import org.hibernate.SessionFactory;51. import org.hibernate.Transaction;52. import org.hibernate.cfg.AnnotationConfiguration;53. import org.hibernate.cfg.Configuration;54. public class HibernateUtil {55. private static SessionFactory sessionFactory;56. public static SessionFactory getSessionFactory() {57.

if (sessionFactory == null) {58.

AnnotationConfiguration cfg = new AnnotationConfiguration();59.

Configuration config = cfg.configure("hibernate.cfg.xml");60.

sessionFactory = config.buildSessionFactory();61.

}62.

return sessionFactory;63. }64. public static Session getSession() {65.

Session sessao = getSessionFactory().openSession();66.

return sessao;67. }68. }69. Arquivo ClienteBean.java:

70. package bean;71. import javax.faces.bean.ManagedBean;72. import javax.faces.bean.SessionScoped;73. import banco.BancoDeClientes;74. import modelo.Cliente;75. @ManagedBean(name = "beanCliente")76. @SessionScoped77. public class ClienteBean {78. BancoDeClientes bdc = new BancoDeClientes();79. Cliente cliente = new Cliente();80. public String salvar(){81. bdc.salvar(cliente);

82. // ------ tesete - visualiza no console --------------83. System.out.println(cliente.getTelefone());84. System.out.println(cliente.getCPF());85. System.out.println(cliente.getNome());86. System.out.println(cliente.getDataCadastro());87. return "sucesso";88. }89. public Cliente getCliente() {90. return cliente;91. }92. public void setCliente(Cliente cliente) {93. this.cliente = cliente;94. }95. }96. Arquivo Cliente.java:

97. package modelo;98. import java.util.Date;99. import javax.persistence.*;100. @Entity101. @Table(name = "ct_cliente")102. public class Cliente {103. @Id104. private String telefone;105. @Column106. private String CPF;107. @Column108. private String nome;109. @Column110. private Date dataCadastro;111. public String getTelefone() {112.

return telefone;113. }114. public void setTelefone(String telefone) {115.

this.telefone = telefone;116. }117. public String getCPF() {118.

return CPF;119. }120. public void setCPF(String cPF) {121.

CPF = cPF;122. }123. public String getNome() {124.

return nome;125. }126. public void setNome(String nome) {127.

this.nome = nome;128. }129. public Date getDataCadastro() {130.

return dataCadastro;131. }132. public void setDataCadastro(Date dataCadastro) {133.

this.dataCadastro = dataCadastro;134. }135. }136. Arquivo hibernate.cfg.xml:

137. 138. 141. 142.

143.

144.

com.mysql.jdbc.Driver145.

jdbc:mysql://localhost:3306/bddados146.

root147.

root148.

149.

true150.

true151.

152.

org.hibernate.dialect.MySQLDialect153.

update154.

155.

156.

157. 158. Arquivo template.xml:159. 160. 161. 165. 166. Portflio em Grupo 5 Semestre167. 168. 169. 170.