3

SUMRIO
1 INTRODUO............................................................................................................
3
2 OBJETIVOS................................................................................................................
4
2.1 Geral.........................................................................................................................
4
2.1.1 Especificos............................................................................................................
4
3 ENGENHARIA E PROJETO DE SOFTWARE..............................................................
5
3.1. Engenharia e Projeto de Software - Proposta de projeto (desafio 1) ...................
5
3.1.2 Engenharia e Projeto de Software - projeto gerencivel baseado no PMBoK
(desafio 2) ......................................................................................................................
5
3.2 PROGRAMAO PARA WEB II Desafio 3.............................................................
6
3.3 PROJETO ORIENTADO A OBJETOS Desafio 4..................................................
6
4 CONCLUSO.............................................................................................................
7
5 REFERNCIAS...........................................................................................................
7

1 INTRODUO
Este 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 OBJETIVOS

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

3.

Sada. A sada gera Sadas a serem escritas novamente no

essas entradas.
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

10

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

11

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.

12

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

13

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)

14

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.

15

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.

16

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 2

De 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
1. Introduo 4
1.1 Finalidade 4
1.2 Escopo 4
1.3 Definies, Acrnimos e Abreviaes 4
1.4 Referncias 4
1.5 Viso Geral 5
2. Viso Geral do Projeto 5
2.1 Finalidade, Escopo e Objetivos do Projeto 5
2.2 Suposies e Restries 5
2.3 Produtos Liberados do Projeto 5
2.4 Evoluo do Plano de Desenvolvimento de Software 5
3. Organizao do Projeto 5
3.1 Estrutura Organizacional 5
3.2 Interfaces Externas 6
3.3 Papis e Responsabilidades 6
4. Processo de Gerenciamento 7
4.1 Estimativas do Projeto 7
4.2 Plano de Projeto 7
4.2.1 Plano de Fase 7
4.2.2 Objetivos das Iteraes 7
4.2.3 Releases 7

17

4.2.4 Programao do Projeto 7

4.2.5 Recursos do Projeto 7
4.3 Monitoramento e Controle do Projeto 7
5. Anexos 9

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.

18

- CRONOGRAMA DAS ATIVIDADES PARA O DESENVOLVIMENTO DO PROJETO

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

19

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.

20

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 as culturas e

estilos organizacionais, os fatores ambientais da empresa, do mercado, da

sociedade e da localizao geopoltica onde o projeto acontece.

21

3.2 PROGRAMAO PARA WEB II DESAFIO 3

1.

Para criao do projeto Java Web foi selecionado a IDE Eclipse e foi estruturado
assim:

2.
3.
4. Foi criado os seguintes arquivos:
5. portfoliogrupo5 > src > banco > BancoDeClientes.java
6. portfoliogrupo5 > src > banco > HibernateUtil.java
7. portfoliogrupo5 > src > bean > ClienteBean.java
8. portfoliogrupo5 > src > modelo > Cliente.java
9. portfoliogrupo5 > src > hibernate.cfg.xml
10. portfoliogrupo5 > WebContent > tema > template.xhtml
11. portfoliogrupo5 > WebContent > views > cliente.xhtml
12. portfoliogrupo5 > WebContent > WEB-INF> lib > [ colocado

aqui ]
13. portfoliogrupo5 > WebContent > WEB-INF> faces-config.xml
14. portfoliogrupo5 > WebContent > WEB-INF> web.xml
15. portfoliogrupo5 > WebContent > index.html
16. portfoliogrupo5 > WebContent > index.xhtml
17.
18.
19.
20.
21.
22.
23.
24. Arquivo BancoDeClientes.java:
25. package banco;
26.
27. import modelo.Cliente;
28.
29. import org.hibernate.Session;
30. import org.hibernate.Transaction;
31.
32. public class BancoDeClientes {
33.

as *.jar necessrias

22
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.

public String salvar(Cliente u) {

Session sessao = null;
Transaction tx = null;
try {

sessao = HibernateUtil.getSession();
tx = sessao.beginTransaction();
sessao.save(u);
tx.commit();

System.out.println("ENTREI =======================>
AQUI = COMMIT");
} catch (Exception ex) {
System.out.println("ENTREI =======================>
AQUI = ROLLBACK");

49.
50.
tx.rollback();
51.
ex.printStackTrace();
52.
} finally {
53.
if (sessao != null) {
54.
try {
55.
sessao.close();
56.
} catch (Exception e) {
57.
e.printStackTrace();
58.
}
59.
}
60.
}
61.
return null;
62.
}
63.
64. }
65.
66.
67.
68.
69.
70.
71.
72.
73.
74.
75.
76.
77.
78.
79.
80. Arquivo HibernateUtil.java:
81. package banco;
82.
83. import org.hibernate.Session;
84. import org.hibernate.SessionFactory;
85. import org.hibernate.Transaction;
86. import org.hibernate.cfg.AnnotationConfiguration;
87. import org.hibernate.cfg.Configuration;
88.
89. public class HibernateUtil {
90.
private static SessionFactory sessionFactory;

23
91.
92.
93.
94.
95.
96.
97.
98.
99.
100.
101.
102.
103.
104.
105.
106.
107.
108.
109.
110.
111.
112.
113.
114.
115.
116.
117.
118.
119.
120.
121.
122.
123.
124.
125.
126.
127.
128.
129.
130.
131.
132.
133.
134.
135.
136.
137.
138.
139.
140.
141.
142.
143.
144.
145.
146.
147.
148.
149.

public static SessionFactory getSessionFactory() {

if (sessionFactory == null) {
AnnotationConfiguration cfg = new AnnotationConfiguration();
Configuration config = cfg.configure("hibernate.cfg.xml");
sessionFactory = config.buildSessionFactory();
}
return sessionFactory;
}
public static Session getSession() {
Session sessao = getSessionFactory().openSession();
return sessao;
}
}

Arquivo ClienteBean.java:
package bean;

import javax.faces.bean.ManagedBean;
import javax.faces.bean.SessionScoped;
import banco.BancoDeClientes;
import modelo.Cliente;
@ManagedBean(name = "beanCliente")
@SessionScoped
public class ClienteBean {
BancoDeClientes bdc = new BancoDeClientes();
Cliente cliente = new Cliente();
public String salvar(){
bdc.salvar(cliente);
// ------ tesete - visualiza no console -------------System.out.println(cliente.getTelefone());
System.out.println(cliente.getCPF());
System.out.println(cliente.getNome());
System.out.println(cliente.getDataCadastro());
return "sucesso";
}
public Cliente getCliente() {
return cliente;
}
public void setCliente(Cliente cliente) {
this.cliente = cliente;
}
}

Arquivo Cliente.java:
package modelo;

24
150. import java.util.Date;
151.
152. import javax.persistence.*;
153.
154. @Entity
155. @Table(name = "ct_cliente")
156. public class Cliente {
157.
@Id
158.
private String telefone;
159.
@Column
160.
private String CPF;
161.
@Column
162.
private String nome;
163.
@Column
164.
private Date dataCadastro;
165.
166.
public String getTelefone() {
167.
return telefone;
168.
}
169.
public void setTelefone(String telefone) {
170.
this.telefone = telefone;
171.
}
172.
public String getCPF() {
173.
return CPF;
174.
}
175.
public void setCPF(String cPF) {
176.
CPF = cPF;
177.
}
178.
public String getNome() {
179.
return nome;
180.
}
181.
public void setNome(String nome) {
182.
this.nome = nome;
183.
}
184.
public Date getDataCadastro() {
185.
return dataCadastro;
186.
}
187.
public void setDataCadastro(Date dataCadastro) {
188.
this.dataCadastro = dataCadastro;
189.
}
190. }
191.
192.
193. Arquivo hibernate.cfg.xml:
194. <?xml version="1.0" encoding="utf-8"?>
195. <!DOCTYPE hibernate-configuration PUBLIC
196.
"-//Hibernate/Hibernate Configuration DTD 3.0//EN"
197.
"http://hibernate.sourceforge.net/hibernate-configuration-3.0.dtd">
198. <hibernate-configuration>
199.
<session-factory>
200.
201.
<!-- Configuraes da conexo -->
202.
<property
name="connection.driver_class">com.mysql.jdbc.Driver</property>
203.
<property
name="connection.url">jdbc:mysql://localhost:3306/bddados</property>
204.
<property name="connection.username">root</property>
205.
<property name="connection.password">root</property>
206.

25
207.
<!-- Impresso do SQL na sada padro -->
208.
<property name="show_sql">true</property>
209.
<property name="format_sql">true</property>
210.
211.
<!-- Dialeto utilizado -->
212.
<property
name="dialect">org.hibernate.dialect.MySQLDialect</property>
213.
<property name="hbm2ddl.auto">update</property>
214.
215.
<!-- Classes anotadas -->
216.
<mapping class="modelo.Cliente" />
217.
218.
</session-factory>
219. </hibernate-configuration>
220.
221. Arquivo template.xml:
222. <?xml version='1.0' encoding='UTF-8' ?>
223. <!DOCTYPE
html
PUBLIC
"-//W3C//DTD
XHTML
1.0
Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
224. <html xmlns="http://www.w3.org/1999/xhtml"
225.
xmlns:h="http://java.sun.com/jsf/html"
226.
xmlns:ui="http://java.sun.com/jsf/facelets"
227.
xmlns:p="http://primefaces.org/ui">
228. <h:head>
229.
<title>Portflio em Grupo 5 Semestre</title>
230. </h:head>
231. <h:body>
232. <p:layout fullPage="true">
233. <p:layoutUnit position="north" size="0"
234. header=":: Desafio 3 ::" resizable="false"
235. closable="false collapsible="false"
236. style="font-size: 20px; font-family: Vedana">
237. </p:layoutUnit>
238. <p:layoutUnit position="west" size="200" header="Menu"
239. resizable="false" closable="false"
240. collapsible="false">
241.
<p:menu style="width: 180px">
242.
<p:submenu label="Administrativo">
243.
<p:menuitem value="Pgina Inicial"
244. url="/index.jsf" />
245.
</p:submenu>
246.
<p:submenu label="Cadastros">
247.
<p:menuitem value="Clientes"
248.
url="/views/cliente.jsf" />
249.
</p:submenu>
250.
</p:menu>
251. </p:layoutUnit>
252.
<p:layoutUnit position="center" header="Sistema">
253.
<ui:insert name="content"></ui:insert>
254.
</p:layoutUnit>
255.
<p:layoutUnit position="south" size="50"
256. header="China Telecom" resizable="false"
257. closable="false" collapsible="false">
258.
</p:layoutUnit>
259.
</p:layout>
260. </h:body>
261. </html>
262.
263. Arquivo cliente.xml:

26
264. <?xml version='1.0' encoding='UTF-8' ?>
265. <!DOCTYPE
html
PUBLIC
"-//W3C//DTD
XHTML
1.0
Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
266. <html xmlns="http://www.w3.org/1999/xhtml"
267.
xmlns:h="http://java.sun.com/jsf/html"
268.
xmlns:ui="http://java.sun.com/jsf/facelets"
269.
xmlns:p="http://primefaces.org/ui">
270. <h:head>
271.
<title>Portflio em Grupo 5 Semestre</title>
272. </h:head>
273.
274. <h:body>
275. <ui:composition template="/tema/template.xhtml">
276.
<ui:define name="content">
277.
<p:growl id="avisos" showDetail="true" life="3000" />
278.
<p:fieldset legend="Cadastro de Clientes"
279. toggleable="true">
280.
<h:form>
281.
<p:focus for="nome" />
282.
<h:panelGrid columns="2">
283.
<h:outputText value="Telefone:" />
284.
<p:inputMask mask="(999)9999-9999"
285. value="#{beanCliente.cliente.telefone}" />
286.
287.
<h:outputText value="CPF:" />
288.
<p:inputMask mask="999.999.999-99"
289. value="#{beanCliente.cliente.CPF}" />
290.
291.
<h:outputText value="Nome:" />
292.
<p:inputText id="nome"
293. value="#{beanCliente.cliente.nome}" />
294.
295.
<h:outputText value="Dt cadastro:" />
<p:calendar
296. value="#{beanCliente.cliente.dataCadastro}" />
297.
</h:panelGrid>
298.
<p:separator style="width: 100%;
299. height: 5px" />
300.
<h:commandButton value="Salvar"
301. action="#{beanCliente.salvar}" />
302.
</h:form>
303.
</p:fieldset>
304.
<p:messages id="mensagens" showDetail="true" />
305.
</ui:define>
306.
</ui:composition>
307. </h:body>
308. </html>
309. Arquivo index.html:
310. <meta http-equiv="REFRESH" content="0;url=index.jsf">
311.
312. Arquivo index.xhtml:
313. <?xml version='1.0' encoding='UTF-8' ?>
314. <!DOCTYPE
html
PUBLIC
"-//W3C//DTD
XHTML
1.0
Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
315. <html xmlns="http://www.w3.org/1999/xhtml"
316.
xmlns:h="http://java.sun.com/jsf/html"
317.
xmlns:f="http://java.sun.com/jsf/core"
318.
xmlns:p="http://primefaces.prime.com.tr/ui"
319.
xmlns:ui="http://java.sun.com/jsf/facelets">

27
320.
321.
322.
323.
324.
325.
326.
327.
328.
329.
330.
331.
332.
333.
334.

<h:head>
<title>Portflio em Grupo 5 Semestre</title>
</h:head>
<h:body>
<ui:composition template="/tema/template.xhtml">
<ui:define name="content">
Seja bem vindo!
</ui:define>
</ui:composition>
</h:body>
</html>

Frameworks usados:
PrimeFaces
Hibernate

3.3 PROJETO ORIENTADO A OBJETOS Desafio 4.

Modelo de Arquitetura

28

Modelo Fsico

Classe de Dominio

29

Classe persistencia

Diagrama de componentes

30

Diagrama de Pacotes

31

32

5 CONCLUSO
O trabalho proporcionou ao grupo uma maior integrao entre os
conhecimentos estudados e a atividade prtica. As empresas tem necessidades
muitas vezes genricas cabe aos profissionais identificarem tais necessidades para
mehor desempenharem seu papel no desenvolvimento de solues em escala,
customizando-as conforme a peculiaridade de cada cliente. Tambm possivel
desenvolver um projeto exclusivo para um cliente, conforme sua vontade.

trabalho com a CHINA TELECOM favoreceu a fixao do contedo estudado no

semestre e promoveu uma reflexo sobre a importncia de um bom gerenciamento
de projeto, bem como, de uma adequada programao Web, para o sucesso nas
atividades dos mais variados modelos de empresas, seja em qual segmento for.

33

5 REFERNCIAS

DVILA, Marcio. PMBOK e Gerenciamento de Projetos. Disponvel em

http://www.mhavila.com.br/topicos/gestao/pmbok.html Acesso em maio/2015.
PERINE, Luiz Claudio. Et al. Engenharia de Software: sistemas II. So Paulo:
Pearson Prentice Hall, 2009.
SUMMERVILLE, Ian. Engenharia de Software. 8 ed. So Paulo: Pearson, 2006.