Vou compartilhar aqui o que eu fiz ate agora Smile

Espero retorno das outras partes

3 DESENVOLVIMENTO
O PMBOK Guide no uma metodologia, pois no distingue os diferentes tipos de projeto
(certamente gerenciar projetos administrativos totalmente diferente de gerenciar
projetos de construo pesada).
No utiliza peculiaridades de linguagem que respeitem a cultura de diferentes tipo
s de empresas e no apresenta modelos especficos de documentos a serem preenchidos.
Resumidamente podemos chamar de manual que descreve o universo de conhecimentos
para o Gerenciamento de Projetos. Transformou-se em um padro fonte de inspirao para
quase todas as metodologias existentes.
3.1 ENGENHARIA E PROJETO DE SOFTWARE
Vamos entender melhor sobre engenharia e projetos de desenvolvimento de um softw
are. Para isso vamos ver o guia Project Management Body of Knowledge ou simplesm
ente Guia PMBOK.
O Guia PMBOK um conjunto de prticas na gesto de projetos organizados pelo institut
o PMI e considerado a base do conhecimento sobre gesto de projetos por profission
ais da rea.
Devemos ter cuidado no escopo do projeto, mantendo foco no projeto que foi passa
do. Para que assim no ocorra erros no projeto, analisando o que ser feito, como va
i funcionar, qual o tipo de usurio, deve-se verificar as documentaes, preocupando-s
e em no acrescentar nada alem do que o projeto esta pedindo.
Algumas expresses:
"Metodologia: Um sistema de prticas, tcnicas, procedimentos e regras usado pelas p
essoas que trabalham em uma disciplina."
"Metodologia de gerenciamento de projetos define um processo, que auxilia uma eq
uipe de gerenciamento de projetos no desenvolvimento e controle das mudanas do pl
ano de gerenciamento do projeto".
Esta expresso esta constantemente mencionada nos processos de Integrao (captulo 4),
cada organizao poder ter um prprio processo.
O PMBOK torna um projeto melhor estruturado e atende as demandas de forma eficie
nte, tendo um conjunto de praticas na construo de um software.
Riscos: O risco aqui de um projeto de conjuntos de condies onde pode ocorrer em fo
rma de oportunidades negativas ou positivas.
Escopo: O gerenciamento do escopo do projeto responsvel por realizar o projeto co
m sucesso, tendo um planejamento criado de um processo plano de gerenciamento de
escopo.
Aquisies: Aaaaaaaa, aaaaa, aaaa. Aaaaa, aaaa e aaaa.
Partes interessadas: Bbbbbb, bbbbbb e assim bbbb. Pois bbbbb, bbbbb.
Aplicaes de conhecimento, habilidades, ferramentas e suas tcnicas nas atividades de
um projeto com finalidade de alcanar um objetivo somente atingido atravs do uso d
e processos e fases.

Agora supondo que a empresa china telecom optasse em desenvolvimento prprio, vamo
s ler o livro Engenharia de Software, de Ian Sommerville:
Capitulo 11 (Projeto de Arquitetura).
O projeto de arquitetura primeiro estagio no processo de projetos.

No livro diz que ele idntica subsistemas e estabelece um framework para controlar
a comunicao dos subsistemas, tambm representa uma ligao critica entre processos de e
ngenharia de projeto e requisitos.
Trs vantagens de projetar e documentar explicitamente uma arquitetura de software
: Comunicao de stakeholders, Analise de sistemas, Reuso em larga escala:
A arquitetura de software serve para negociar requisitos de sistema e estruturar
discusses com os clientes, desenvolvedores e gerentes. uma ferramenta essencial
parra gerenciamento de complexidade, ocultando detalhes e focando as abstraes prin
cipais do sistema.
Se o desempenho for um requisito crtico a aplicao deve localizar operaes criticas den
tro de subsistemas e usar componentes de alta granularidade em detrimento dos de
baixa granularidade para reduzir a comunicao entre eles.
Se a facilidade de manuteno for um requisito crtico, a arquitetura de sistemas deve
ser projetada usando componentes de baixa granularidade e auto contidos que pos
sam ser prontamente mudados.
Esses diagramas de blocos so bons para comunicao entre stakeholders e para o planej
amento do projeto pois no esto abarrotados de detalhes, j para a arquitetura no so to
bons, pois no mostram relacionamento entre os componentes do sistema.

Durante o processo de projeto de arquitetura os arquitetos de sistemas devem ser

feita algumas perguntas:
Existe uma arquitetura genrica de aplicao que possa funcionar como um modelo para o
sistema que est sendo projetado?
Como o sistema ser distribudo ao longo de vrios processadores?
Qual ou quais estilos de arquitetura so apropriados para o sistema?
Qual ser a abordagem fundamental usada para estruturar o sistema?
Como as unidades estruturais de um sistema sero decompostas em mdulos?
Qual estratgia ser utilizada para controlar a operao das unidades do sistema?
Como o projeto de arquitetura ser avaliado?
Como a arquitetura do sistema deve ser documentada?
Um modelo esttico de estrutura que mostra os subsistemas ou componentes desenvolv
idos como unidades separadas.
Um modelo dinmico de processo que mostra como o sistema esta organizado em proces
sos em tempo de execuo.
A organizao de um sistema reflete a estratgia bsica usada para estrutur-lo. Voc precis
a tomar decises sobre o modelo geral organizacional de um sistema com antecedncia
no processo de projeto de arquitetura. A organizao pode refletir diretamente na es
trutura do subsistema.
A
o
.
O
o

vantagem de um modelo cliente servidor que ele uma arquitetura distribuda. O us

efetivo de sistemas em rede pode ser feito com muitos processadores distribudos
fcil adicionar um novo servidor e integr-lo ao restante do sistema.
modelo em camadas organiza um sistema em camadas, cada uma das quais fornecend
um conjunto de servios.

A abordagem em camadas apia o desenvolvimento incremental de sistemas. A medida q

ue uma camada desenvolvida alguns servios fornecidos por essa camada podem ser di
sponibilizados para os usurios. Essa arquitetura tambm modificvel e portvel.
Uma desvantagem da abordagem em camadas que a estruturao de sistemas dessa maneira
pode ser difcil. As camadas mais internas podem fornecer recursos bsicos, como ge
renciamento de arquivos, necessrios em todos os nveis.
Depois que a organizao geral do sistema foi escolhida, precisa-se tomar uma deciso
sobre a abordagem a ser usada na decomposio de subsistemas em mdulos.
Um modulo normalmente um componente de sistema que fornece um ou mais servios par
a outros mdulos. Ele faz uso de servios fornecidos por outros mdulos.existem duas e

stratgias principais que voc pode usar ao decompor um subsistema em mdulos.

Um modelo de arquitetura orientado a objetos estrutura o sistema em um conjunto
de objetos no firmemente acoplados com interfaces bem definidas. Os objetos chama
m servios oferecidos por outros objetos.
Uma decomposio orientada a objetos esta relacionada a classes de objetos, seus atr
ibutos e suas operaes. A vantagem que implementao de objetos pode ser modificada se
m afetar outros objetos.
A desvantagem que para usar servios os objetos devem fazer referencia explicita a
o nome e a interface de outros objetos.
No pipelining orientado a funes ou modelo de fluxo de dados, as transformaes process
am suas entradas e produzem sadas. Os dados fluem de uma para outra funo e so transf
ormados ao moverem
se seqencialmente. Cada etapa implementada como uma transformao.
Os dados de entrada fluem atravs dessas transaes ate serem convertidos em dados se
sada.
Vantagens: Apoiar o reuso de transformaes.
Os modelos de controle tem como objetivo controlar subsistemas de maneira que se
us servios sejam entregues no lugar certo e no tempo certo.
Modelos de controle so usados em conjunto com estilos de estrutura. Todos os esti
los de estrutura que foi explicado podem ser implementados por meio de controle
centralizado ou baseado em eventos.
Em modelo de controle centralizado, um subsistema designado como controlado de s
istema e tem a responsabilidade pelo gerenciamento da execuo de outros subsistemas
. Tendo duas classes, dependendo se forem executados seqencialmente ou paralelame
nte.
O modelo retorno comea no topo da hierarquia de sub
rotina e, atravs de chamadas d
e sub-rotinas, passa para os nveis mais baixos na arvore, so aplicados em modelos
seqenciais.
O modelo gerenciados, aplicados em modelos concorrentes. Sistema concorrente pro
jetado como um gerenciador de sistema e controla o inicio, a parada e a coordenao
de outros processos do sistema.

As arquiteturas de referencia no so geralmente consideradas um roteiro de implemen

taes. Em vez disso, sua principal funo ser um meio de discusso de arquiteturas de dom
io especifico e de comparao de sistemas diferentes em um domnio.
Uma proposta de modelo de referencia um modelo para ambientes CASE que identific
a cinco conjuntos de servios que um ambiente CASE deve fornecer. Ele deve tambm fo
rnecer recursos de plug-in para ferramentas CASE individuais que usam esses serv
ios.

Capitulo 12 (Arquitetura de Sistemas distribudos).

Um sistema bem distribudo aquele em que as informaes em fase de processamento so dis
tribudas a vrios computadores.
Vantagens de usar uma abordagem distribuda para desenvolvimento de sistemas: Comp
artilhamento de recursos, Abertura, Concorrncia, Escalabilidade, Tolerncia a defei
tos.
Esses sistemas de distribuio comparados aos sistemas que operam com um processador
ou com um cluster de processadores podem ter algumas desvantagens como: Complex
idade, Proteo, Gerenciamento, Imprevisibilidade e Defeitos que em uma maquina pode
m se propagar a outra maquinas com conseqncias inesperadas.
Tipos diferentes de arquiteturas de sistemas distribudos:

Arquitetura cliente-servidor. o sistema como um conjunto de servios fornecidos ao

s
clientes que fazem uso desses servios. Os servidores e clientes so tratados de man
eiras diferentes nesses sistemas.
Arquiteturas de objetos distribudos. Podemos pensar no sistema como um conjunto d
e objetos que interagem e cuja a localizao irrelevante. No h distino entre cliente e
ervidor.
Tanto a arquitetura cliente-servidor e a arquitetura de objetos distribudos so amp
lamente usadas no setor, mais a aplicao ocorre geralmente dentro de uma nica organi
zao. A organizao , portanto, intra-organizacional.

Arquitetura de multiprocessadores
O multiprocessador So processos que podem ser executados separados. Esse modelo t
omam 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 capac
idade de recuperao do sistema
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 objetos distribudos em lugar de uma arquitetura cliente-servid
or adequada para esse tipo de aplicao por trs razes:
O modelo lgico do sistema no um dos fornecimentos de servios em que existem servios
distintos de gerenciamento de dados.
Pode adicionar bancos de dados ao sistema sem grande interrupes.
A maior Desvantagem que elas so mais complexas do que sistemas cliente-servidor.
CORBA
Existem quatro elementos principais desse padro:
Um modelo de objeto para objetos de aplicaes.
Um requisitor de objetos.
Um conjunto de servios de objetos.
Um conjunto de componentes comum.
O Corba considera um objeto como se fosse um encapsula mento de atributos e serv
ios, como normal em objetos.
Os objetos corba tem um nico identificador chamado de referencia de objeto intero
peravel. 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 int
erfaces. O ORB cuida da comunicao entre os objetos.os objetos que se comunicam no p
recisam 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 interf
ace a implementao dos servios.
Os componentes verticais so componentes especficos de um domnio de aplicao. Os compon
entes horizontais so componentes de propsito geral, como componentes de interface
com o usurio.

Por motivo de segurana e interoperabilidade, a computao distribuda foi implementada

inicialmente em nvel organizacional. Uma organizao tem uma serie de servidores e di
stribui sua carga computacional entre eles. Devido ao fato de eles estarem todos
localizados dentro da mesma organizao, podem ser aplicados padres e processos oper
acionais locais.

A essncia de um servio, que o fornecimento dos servios independente da aplicao que u

a o servio. Os provedores de servios podem desenvolver servios especializados e ofe
rec-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 po
r meio de navegar web, e o acesso direto aos repositrios de informaes por outros pr
ogramas no era pratico.
Os trs padres fundamentais que 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 serv
io usadas pelos solicitantes do servios para descobrir servios, pode ser organizada
.
Todos estes padres baseados em XML.
Capitulo 13 (Arquitetura de aplicaes).
Aplicaes 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 d
os dados que so processados.
Os sistemas de processamento em lotes so normalmente usados em aplicaes de negcios n
as quais as operaes similares so realizadas sobre uma grande quantidade de dados.
Os sistemas de processamento de dados selecionam os dados de registros de entrad
a 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 transaes so projetados para processar solicitaes de informaes por usur

de um banco de dados. Tecnicamente uma seqncia de operaes tratada como uma unidade
simples.
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 proce
ssamento de entrada/sada. A solicitao processada por alguma lgica especifica da apli
cao.
A estrutura entrada-processo-sada se aplica aos muitos sistemas de processamento
de transaes. Alguns desses sistemas so verses interativas de sistemas de processamen
to de lotes.
Em sistemas como os de contabilidade de clientes de um banco, pode haver diferen
tes maneiras de interagir com o sistema. Muitos clientes interagiro por meio de c
aixas 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 naveg
adores WEB.

Os sistemas de processamento de linguagens aceitam uma linguagem natural ou arti

ficial como entrada e geram alguma outra representao dessa linguagem como sada.
Em engenharia de software, os sistemas de processamento de linguagens mais ampla
mente usados so os compiladores que traduzem uma linguagem artificial de programao
de alto nvel em cdigo de maquina. Mais outros sistemas de processamento de linguag
ens 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 lingua
gem em outra.
Os tradutores em um sistema de processamento de linguagens tem uma arquitetura g
enrica que inclui os seguintes componentes:
Um analisador lxico, uma tabela de smbolos, um analisador sinttico, uma rvore de sin
taxe, um analisador semntico e um gerador de cdigo.

Capitulo 29 (Gerenciamento de Configuraes).

Gerenciamento de configuraes o desenvolvimento e o uso de padres e procedimentos pa
ra o gerenciamento de sistemas de software em desenvolvimento. Ha muitas razes po
r que os sistemas existem em diferentes configuraes.
Configuraes podem ser produzidas para diferentes computadores, diferentes sistemas
operacionais, incorporando funes especificas para 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 ma
neira controlada e liberar novas verses para clientes certos no momento certo.
O plano de gerenciamento de configuraes descreve os padres e procedimentos que deve
m 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.
Em um grande sistema de software, pode haver mdulos de milhares de cdigos fonte, s
cripts de testes, documentos de projeto etc. Eles so produzidos por pessoas difer
entes e, quando criados, podem ser denominados com nomes similares ou idnticos. P
ara manter a rastreabilidade de todas essas informaes de maneira que o arquivo cer
to possa ser encontrado quando for necessrio voc necessita de um esquema de identi
ficao consistente para todos os itens no sistema de gerenciamento de configuraes.
Todos os documentos podem ser teis para a evoluo do sistema. O esquema de identific
ao de itens de configurao deve atribuir um nico nome para todos os documentos sob con
trole de configurao. No esquema de atribuio de nomes, voc pode desejar evidenciar a r
elao entre os itens para garantir que os documentos relacionados possuam uma mesma
raiz em seus nomes.
O banco de dados de configurao utilizado para registrar todas as informaes relevante
s sobre as configuraes de sistema e os itens de configurao. Como parte do processo d
e CM, deve-se definir o esquema do banco de dados de CM, os formulrios para colet
ar informaes para serem registradas no banco de dados e procedimentos para registr
o 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 sis
tema de gerenciamento usada para armazenar e gerenciar os documentos formais do
projeto.
As necessidades e requisitos organizacionais alteram-se durante a vida til de um
sistema. Isso significa que voc precisa fazer as mudanas correspondentes no sistem
a de software.
Para garantir que essas mudanas sero aplicadas ao sistema de maneira controlada, v
oc precisa de um conjunto de procedimentos de gerenciamento de mudanas apoiado por
ferramentas.
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 par

a o sistema. Uma vez que o formulrio de solicitao de mudana enviado, ele deve ser re
gistrado no banco de dados de configurao. A solicitao de mudana ento analisada para v
rificar se a mudana solicitada necessria.
Para mudanas validas, o estagio seguinte a avaliao da mudana e o custo. 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 com
ponentes relacionados.

Uma das trs tcnicas bsicas para identificao da verso de componentes Numerao de vers
componente recebe um numero explicito e nico de verso. Isso o mais comumente usado
no esquema de identificao.
"A verso de componente identificada pelo conjunto de solicitaes de mudanas que se ap
licam ao componente."
Processos de gerenciamento de configuraes so normalmente padronizados e envolvem ap
licaes de procedimentos predefinidos. Eles requerem o gerenciamento cuidadoso de g
rande quantidade de dados e essencial a ateno aos detalhes.
Quando um sistema est sendo construdo com base em verses de componentes, um nico err
o de gerenciamento de configurao pode significar que o software no ir operar adequad
amente.
Conseqentemente, o apoio de um ferramenta CASE essencial para o gerenciamento de
configurao. Essas ferramentas podem ser combinadas para criar uma rea de trabalho p
ara apoiar todas as atividades de CM.

3.2 PROGRAMAO PARA WEB II

Falar aqui da programao web etc e citar frameworks

3.2.1 Comparao de frameworks

Faltando aki
3.2.2 Relacione custo de frameworks
Melhora a modularizao
encapsula mento dos detalhes volteis de implementao atravs
interfaces estveis.
Aumenta a reutilizao
definio de componentes genricos que podem ser replicados para
criar novos sistemas.
Extensibilidade
favorecida pelo uso de mtodos hooks que permitem que as aplicaes
estendam interfaces estveis.
Inverso de controle
IoC
o cdigo do desenvolvedor chamado pelo cdigo do framework
Dessa forma, o framework controla a estrutura e o fluxo de execuo dos programas.
//aaaaa
3.2.3 Java web
Bbbbb.
3.3 Projeto Orientado a Objeto
Aaaaaa.

CONCLUSO
Faltando aki
REFERNCIAS
Ate o momento so tenho os livros como referencia