trabalho individual v semestre

8/18/2019 Trabalho Individual v Semestre

1/28


2/28


3/28

SUMÁRIO

1 INTRODUÇÃO.......................................................................................................3

2 objetivo..................................................................................................................4

3 Engenharia e rojeto !e So"t#are......................................................................$

3.1 ri%&o%.....................................................................................................................$

3.2 e%&o'o...................................................................................................................(

3.3 "orne&e!ore%........................................................................................................)

3.4 'arte% intere%%a!a%.............................................................................................)

4 re%enha !o% &a'it*+o% 11, 12, 13 e 2- !o +ivro ian %oervi++e.....................-

4.1 'rojeto !e ar/*itet*ra..........................................................................................-4.2 De&i%0e% !e 'rojeto !e ar/*itet*ra..................................................................11

4.3 Organiao !e %i%tea....................................................................................12

4.3.1 Mo!e+o re'o%itrio.....................................................................................12

4.3.2 O o!e+o &+iente5%ervi!or.........................................................................13

4.3.3 O o!e+o e &aa!a%...............................................................................13

4.4 e%ti+o% !e !e&o'o%io o!*+ar...................................................................13

4.$ o!e+o% !e &ontro+e..........................................................................................144.$.1 6ontro+e &entra+ia!o.................................................................................14

4.$.2 Si%tea% orienta!o% a evento%.................................................................14

4.( ar/*itet*ra% !e re"eren&ia.................................................................................1$

4.) 7r/*itet*ra !e %i%tea% %*b!i%trib*i!o%........................................................1$

4.8 ar/*itet*ra% !e a'+i&a0e%................................................................................1(

4.- 9EREN6I7MENTO DE 6ON:I9UR7Ç;ES......................................................1)

4.-.1 +anejaento !e geren&iaento !e &on"ig*ra0e%...............................18

$ RO9R7M7ÇÃO 7R7 [email protected]

$.2 Re+a&ione o% &*%to%Abene"B&io% !e *%ar frameworks no !e%envo+viento

Web.............................................................................................................................2C

$.3 rograao ?ava Web >'+ata"ora !e !e%[email protected]

( RO?ETO 6IN7 TEE6OM.............................................................................24

(.1 7r/*itet*ra *%a!a e "rae#orF........................................................................24

(.2 a!r0e% !e 'rojeto% *ti+ia!o...........................................................................24

(.3 =an&o !e !a!o%.................................................................................................24


4/28

) 6ON6USÃO......................................................................................................2(

RE:ERGN6I7S...........................................................................................................2)


5/28

1 INTRODUÇÃO

Este trabalho é voltado as competências de riscos, escopo, fornecedores, e partes

interessadas, segundo o PMBoK.

O principal objetivo é deiar o leitor bem informado !uanto o uso das normas e

regras !ue na maioria das ve"es n#o aparece no final do produto, programas e

soft$are. %este caso abordaremos algumas fases da Engenharia de soft$are.

&nicialmente vamos falar sobre a engenharia e 'rojeto !e %o"t#are e também

rograao 'ara


6/28

2 O=?ETIHO

-o final desta pes!uisa !uero deiar o leitor ou a !uem de alguma

forma tenha interesse no conhecimento de como normalmente s#o planejados e

documentados os programas, soft$are e tudo !ue envolvem a tecnologia do século

&, tendo acesso a um breve relato de como funciona.

/evo também salientar !ue a!ui é s0 uma pes!uisa superficial e depouca profundidade, levando em considera'#o de todo o conteto !ue envolve a

compleidade dos programadores, analistas e desenvolvedores modernos.

/efendendo a tese de !ue o bem maior da humanidade é a

informa'#o, é preciso ter dados bem normali"ados de boa !ualidade e acima de

tudo, bem protegidos.

1


7/28

3 EN9EN7RI7 E RO?ETO DE SO:T


8/28

de riscos vem se tornando cada ve" mais relevante neste conteto.

)abendo de todas estas possibilidades, preciso antes de !ual!uer in7cio de

um projeto, preciso levantar todas as informa'(es, para !ue meu projeto n#o

fracasse, embora n#o posso di"er >??@ !ue isto n#o v2 acontecer. Mas se eu posso

planejar atividades e responsabilidades, para o cumprimento de todas as metas,

preciso também prever riscos, !ue podem atrapalhar o desempenho na cria'#o do

meu projeto.

Entendo !ue posso dividir em três 2reas os riscos, sendoA

• iscos de projetosA onde posso identificar, problemas !ue podem ocorrer em

or'amento, cronograma, pessoal, recursos de clientes e re!uisito.

• iscos técnicosA problema com implementa'#o do projeto, interface

verifica'#o e manuten'#o.

• iscos do neg0cioA estes s#o os mais dif7ceis para serem detectados, por !ue

s0 ocorre !uando os produtos j2 est#o em fase de conclus#o do projeto ou

até mesmo j2 conclu7do.

Ca" parte das boas pr2ticas de cria'#o ou construtores de soft$are, a an2lise

de riscos. Der conhecimento das possibilidades de erros ou falhas antes das

mesmas surgirem ajuda na solu'#o das mesmas, com mais rapide" e menos custos.

3.2 ES6OO

O gerenciamento do escopo, tem o objetivo principal, definir e manter o

desenvolvimento do projeto dentro do !ue foi desenhado, controlando o !ue deve e

o !ue n#o deve estar inclu7do no projeto, tendo a seguran'a, !ue é realmente a

necessidade do cliente, e !ual!uer mudan'a !ue venha acontecer dever2 ter oconsentimento do cliente.

ealmente o escopo é de grande import;ncia e a mudan'a s0 tem !ue

acontecer se eistir uma situa'#o onde isto é realmente inevit2vel, por !ue além de

mudar todo o projeto inicial, gerando custos etras, onde talve" o cliente n#o !ueira

arcar.

/epois de definido todos os, re!uisitos e ferramentas necess2rias para um

determinado projeto, depois colocado tudo no papel e validado com seu cliente,

segue o escopo palavra de origem grega !ue significa 3a!uele !ue vigia, !ue

protege4, a meta !ue foi determinada ser2 registrada e seguida pelo escopo.


9/28

3.3 :ORNE6EDORES

Est2 2rea também conhecida como 3-!uisi'(es4 tem como atribui'#o

descrever os processos de compras ou ad!uirir produtos, servi'os ou resultados

além de gerenciar projetos. %esta 2rea também tem o objetivo de determinar o !ue

se !uer ad!uirir, de !uem se !uer ad!uirir, receber as respostas dos fornecedores e

selecionar o fornecedor, como se dar2 o gerenciamento dos contratos, pagamentos,

se as entregas est#o de acordo com o !ue foi estabelecido, pagar o fornecedor, e

por 8ltimo formali"ar a finali"a'#o do contrato.

Os processos dessa 2rea s#oA planejar as a!uisi'(es, reali"ar as a!uisi'(es,

administrar as a!uisi'(es e encerrar as a!uisi'(es.Entende:se por fornecedores, todas as pessoas ou departamentos !ue de

alguma forma, fornece pe'as, matérias, substancias ou !ual!uer outro material

necess2rio para o desenvolvimento de um projeto.

.1 7RTES INTERESS7D7S

Ca"endo saber !ue 3partes interessadas4 do termo staFeholdes, s#o todas as

pessoas e organi"a'(es envolvidas no projeto, ou cujos interesse podem ser

positivas ou negativamente afetadas pela reali"a'#o ou pelos resultados do grupo.

Podendo estas eercer influência sobre o projeto e sobre os membros da

e!uipe do projeto.

Guando se inicia um projeto a e!uipe de gerenciamento, precisa identificar as

partes interessadas internas e eternas. -o longo do planejamento e da eecu'#o

do projeto, o gerente do projeto e sua e!uipe devem gerencia as diferentes

necessidades, preocupa'(es e epectativas das partes interessadas, bem como a

influência destas no projeto, para garantir um resultado bem:sucedido.

Podemos descrever alguns eemplos de poss7veis partes interessadasA

• PatrocinadorA pessoa ou grupo !ue fornece os recursos financeiros para a

reali"a'#o do projeto, e !ue também provê o aval estratégico e pol7tica !ue

viabili"a e promove o objeto e o defendeH

• - e!uipe do projeto, !ue inclui gerente do projeto, a e!uipe de gerenciamento

do projeto, e todo restante da e!uipe !ue eecutam o trabalho no projeto e

n#o est#o necessariamente envolvidas com gerenciamentoH

I


10/28

• Jlientes e usu2riosH

• Presidentes, donos e eecutivosH

• -cionistas e investidoresH

• Cornecedores e parceiros comerciaisH

• JoncorrentesH

• overnos, em suas diferentes esferas e poderesH

• Etc.....

Outros elementos !ue influenciam projetos s#o culturas e estilos

organi"acionais, bem como os fatores ambientais da empresa do mercado, da

sociedade e da locali"a'#o geopol7tica onde o projeto acontece.

*


11/28

4 RESEN7 DOS 67ITUOS 11, 12, 13 E 2- DO IHRO I7N SOMMERHIE

O livro usado para perceber estas informa'(es, é destinado aos estudantes

dos cursos de gradua'#o e p0s:gradua'#o e a engenheiros de soft$are !ue atuam

no comercio e na ind8stria.

Ele pode ser usado em cursos de engenharia de soft$are em geral ou em

outros cursos, como os de programa'#o avan'ada, especifica'#o de soft$are,

projeto ou gerenciamento de soft$are.

/esta forma faremos uma pe!uena men'#o em forma de resenha dos

cap7tulos citados, inclusive usando a sua estrutura.

1.> RO?ETO DE 7RUITETUR7

Objetivo%

O objetivo deste capitulo apresentar os conceitos de ar!uitetura de soft$are e

projeto de ar!uitetura. -p0s ler este cap7tulo, vocêA

Jompreendera por !ue o projeto de ar!uitetura de soft$are é importanteH )aber2 !uais decis(es devem ser tomadas sobre a ar!uitetura de sistema

durante o processo de projeto de ar!uiteturaH Der2 sido apresentado a três estilos complementares de ar!uitetura !ue

abrangem, a organi"a'#o geral, decomposi'#o modular e controle de

sistemasH Jompreender2 como as ar!uiteturas de referências s#o usadas para

comunicar conceitos ar!uiteturas e para avaliar ar!uiteturas de sistemas.

6onteJ!o

>>.> /ecis(es de projeto de ar!uitetura

>>.L Organi"a'#o de sistema

>>. Estilo de decomposi'#o modular

>>.1 Modelos de controle

>>.= -r!uiteturas de referencia


12/28

Os sistemas chamados grandes s#o sempre decompostos ou divididos em

subsistemas !ue fornecem algum conjunto de servi'os relacionados, sendo !ue é da

fun'#o da ar!uitetura de soft$are identificar estes subsistemas e estabelecer um

frame$orF, para controlar a comunica'#o entre estes subsistemas.

O processo de projeto de ar!uitetura envolve o estabelecimento de um

frame$orF b2sico, com fun'#o especifica a identificar estas comunica'(es entre os

subsistemas.

Bass et al.L?? eplica três vantagens de projetar e documentar uma

ar!uitetura de soft$areA

>. Jomunica'#o de staFeholders. - ar!uitetura é uma vis#o de auto n7vel do

sistema, !ue pode ser usada em outras fases do sistema.L. -nalise do sistema. Dornar a ar!uitetura do sistema eplicita no in7cio do

desenvolvimento do sistema re!uer alguma an2lise. -s decis(es tomadas no

in7cio, ter2 um efeito na !ualidade final do sistema.. euso em grande escala. . /esempenho. )e o desempenho for um re!uisito critico, a ar!uitetura deve

ser j2 projetada, para locali"ar opera'(es cr7ticas dentro de alguns

subsistemas, com t#o pouca comunica'#o entre eles.L. Prote'#o. )e a prote'#o for o re!uisito critico, tem !ue usar uma estrutura

em camadas, onde estes itens ser#o protegidos, com alto n7vel de valida'#o.

>?


13/28

. )eguran'a. )e a seguran'a for um re!uisito critico, precisa colocar as

opera'(es voltadas a elas em um 8nico ou pe!ueno n8mero de subsistemas.

Evitando problemas de valida'#o e custos.

1. /isponibilidade. )e a disponibilidade for um re!uisito critico, precisa ter componentes redundantes e assim !ue poss7vel substituir e atuali"ar, sem

parar o sistema.=. Cacilidade de manuten'#o. )e a facilidade de manuten'#o for o item critico,

deve projetar com baia granularidade.

Podemos di"er !ue a decomposi'#o de ar!uitetura é necess2ria para

estruturar, organi"ar e especificar, os sistemas maiores, onde cada diagrama de

bloco representaria um subsistema substancial ou independente.%aturalmente, n#o é uma decis#o f2cil, em decompor um sistema em

subsistemas, pois tem !ue ficar atento aos re!uisitos, se eles mudam provavelmente

ser2 locali"ada a mudan'a e n#o distribu7da entre os subsistemas.

4.2 DE6IS;ES DE RO?ETO DE 7RUITETUR7

O projeto de ar!uitetura é um processo !ue re!uer além de muito

conhecimento do ar!uiteto, precisa !ue o mesmo eer'a seu senso criativo, pois

durante o processo eistem muitas perguntas !ue precisam ser respondidas, com

uma resposta satisfat0ria, pois s#o vitais para o funcionamento ou n#o do projeto.

E s#o elasA

>. Eiste uma ar!uitetura genérica de aplica'#o !ue possa funcionar como

modelo para o sistema !ue est2 sendo projetadoL. Jomo o sistema ser2 distribu7do ao longo de v2rios processadores. Gual ou !uais os modelos de ar!uitetura s#o apropriados para o sistema1. Gual ser2 a abordagem fundamental usada para estruturar o sistema=. Jomo as unidades estruturais de um sistema ser#o decompostas em

m0dulos. Gual estratégia ser2 usada para controlar a opera'#o das unidades no

sistemaI. Jomo o projeto de ar!uitetura ser2 avaliado

*. Jomo a ar!uitetura do sistema deve ser documentadaEmbora cada sistema de soft$are seja 7mpar, eles na maioria das ve"es, tem

>>


14/28

suas ar!uiteturas parecidas.

Ent#o ao projetar você deve escolher !uanto do conhecimento das ar!uiteturas

você poder2 reusar.

- ar!uitetura pode ser do tipo, um cliente:servidor ou em camadas.

O processo de projeto de ar!uitetura é um documento, onde também pode se

incluir representa'(es gr2ficas e tetos descritivos associados, como est2

estruturado o sistema em seus subsistemas, !ual foi a abordagem adotada e como

est2 estruturado os subsistemas nos m0dulos. -ssim sendo os modelos de

ar!uitetura a ser desenvolvidos podem incluir.

>.


15/28

4.3.2 O o!e+o &+iente5%ervi!or

Este modelo de ar!uitetura é um modelo em !ue o sistema é organi"ado

como um conjunto de servi'os e servidores e clientes associados !ue acessam e

usam os servi'os. %este modelo tem os seguintes componentesA

>. Os servidores !ue guardam os servi'os dados, para os clientes.L.


16/28

decomposto em subsistemas. Para !ue os subsistemas entreguem seus servi'os no

lugar e tempo certo é utili"ado os modelos de controle !ue lidam com o fluo de

controle entre subsistemas.

Eistem dois estilos genéricos de controles usados em sistemas de soft$areA

>. Jontrole centrali"ado. Onde um subsistema gerencia os outros, iniciando e

parando os outros.L. Jontrole baseado em eventos. %este caso ao invés de um subsistema

gerenciar, cada subsistema pode responder a eventos gerados eternamente.

Estes modelos de controles s#o usados em conjunto de estruturas.

1.=.> 6ontro+e &entra+ia!o

Jomo disse antes este modelo um subsistema é designado como controlador

e tem a responsabilidade de gerenciar a eecu'#o dos outros. Este tipo ainda é

dividido em duas classes.

>. Modelo chamada:retorno. Este é o conhecido modelo top:do$n de sub:rotina

onde este controle come'a no topo.L. O modelo gerenciador. Este modelo é aplic2vel a sistemas concorrentes.

4.$.2 Si%tea% orienta!o% a evento%

Em modelos de controles centrali"ados as decis(es de controle s#o

geralmente determinadas pelos valores de algumas vari2veis de estado do

sistema.

Estes s#o regidos pelos eventos eternos, n#o precisar ser um sinal bin2rio,

neste caso um sinal pode assumir uma série de eventos ou entrada, baseada em

menu.

- diferen'a entre um evento e uma entrada simples é !ue o evento est2 fora

de controle do processo !ue o manipula.

4.( 7RUITETUR7S DE RE:EREN6I7

Os modelos ar!uiteturais anteriores s#o modelos gerais, podendo ser aplicados em muitas classes e aplica'(es. Jomo estes modelos gerais podem

>1


17/28

ser aplicados os espec7ficos também podem ser usados, embora sejam

diferentes em suas instancias, suas estruturas comuns podem ser reutili"adas.

- finalidade principal da ar!uitetura referenciada é ser um meio de

classifica'#o e compara'#o de ferramentas case integrados. -lém disso, ela

pode ser usada para ensinar, destacando as caracter7sticas principais desses

ambientes, e para discuti:los de maneira genérica.

1.I 7RUITETUR7 DE SISTEM7S SU=DISTRI=UIDOS

Guase todos os sistemas baseados em grandes computadores s#o sistemas

distribu7dos. )endo a!ueles !ue as informa'(es em fase de processamento s#odistribu7das em v2rias ma!uinas, em ve" de ficar s0 em um local.

- engenharia de sistema distribu7do e soft$are tem muito em comum, mas

eistem !uest(es especificas !ue devem ser levadas em conta ao projetar esse tipo

de sistema.

)#o vantagens de se usar umas abordagens de desenvolvimento de

sistemas distribu7dosA

>. )#o sistemas !ue permite o compartilhamento de recursos de

hard$are e soft$are, como discos, impressoras, ar!uivos e compiladores !ue

podem estar em diferentes computadores na rede.L. )#o sistemas !ue geralmente permite a combina'#o de e!uipamentos

e soft$ares de fabricantes diferentes.. Em termos de concorrência no sistema distribu7do, v2rios processos

podem operar ao mesmo tempo e em computadores diferentes.1. )#o sistemas escalon2veis, permitindo a implementa'#o de novos

recursos a atende 9 demanda futura.

=. )#o mais tolerantes a defeitos.Os sistemas distribu7dos podem suportar compartilhamentos de recursos,

abertura, concorrência, escalabilidade, toler;ncia a defeitos e transparência.

Os sistemas cliente:servidor s#o sistemas distribu7dos nos !uais o sistema é

modelado como um conjunto de servi'os fornecidos por servidores para processos

clientes.

Em um sistema cliente:servidor, a interface com o usu2rio sempre funciona

em um cliente, e o gerenciamento de dados é fornecido pelo servidor compartilhado.Em uma ar!uitetura de objetos distribu7dos n#o h2 distin'#o entre cliente e

>=


18/28

servidores. Os objetos fornecem servi'os gerais !ue podem ser chamados a partir

de outros objetos.

Os sistemas de objetos distribu7dos re!uerem um middle$are para cuidar

das comunica'(es entre os objetos e permitir !ue os objetos sejam adicionados e

removidos do sistema.

Os padr(es JOB- s#o um conjunto de padr(es para middle$are !ue

suporta ar!uitetura de objetos distribu7dos.

-s ar!uiteturas ponto a ponto s#o ar!uiteturas descentrali"adas nas !uais

n#o h2 clientes e servidores distintos. -s computa'(es podem ser distribu7das em

muitos sistemas e organi"a'(es diferentes.

)istemas orientados a servi'os s#o criados pela liga'#o de servi'os desoft$are fornecidos por v2rios fornecedores de servi'os. . Jomo um ponto de partida para o processo de projeto de ar!uitetura.L. Jomo um checFlist do projeto. )e você desenvolveu um projeto de

ar!uitetura de sistema, é poss7vel par2:lo com a ar!uitetura genérica de aplica'(es,

para checar se falta considerar algum componente importante de projeto.. Jomo uma maneira de organi"a'#o do trabalho da e!uipe de

desenvolvimento.1. Jomo meio de avalia'#o de componentes para reuso.

=. Jomo vocabul2rio para conversar sobre tipos de aplica'(es.

>


19/28

4.- 9EREN6I7MENTO DE 6ON:I9UR7Ç;ES

O gerenciamento de configura'#o é o desenvolvimento e o uso de padr(es e

procedimento para o gerenciamento de sistemas de soft$are em desenvolvimento.

Estes procedimentos de gerenciar as configura'(es definem como registrar

e processar mudan'as de sistema, como relaciona:los aos componentes do sistema

e os métodos usados para identificar diferentes vers(es dele. Estas ferramentas s#o

usadas para arma"enar vers(es de componentes do sistema. )istemas constru7dos

com base nesses componentes e rastrear os releases da vers#o do sistema para

clientes.Este gerenciamento muitas das ve"es s#o considerados parte do

gerenciamento de !ualidade do soft$are, onde o mesmo gerente fica respons2vel

pelas duas facetas do gerenciamento.

Pensando na situa'#o real, onde eistem diversas configura'(es diferentes,

para computadores diferentes, clientes diferentes, setores diferentes, o gerente de

configura'(es tem as responsabilidades de manter a rastreabilidade, assegurando

!ue as novas vers(es sejam derivadas de maneira controlada e liberar novasvers(es para clientes certos no momento certo.

O gerenciamento de configura'(es nos projetos 2geis e r2pido n#o pode

estar baseado em procedimentos burocr2ticos pois desacelera o processo do

desenvolvimento. -ntes seja usado nos projetos mais compleo e grandes.

Preferencialmente para os processos 2geis usam ferramentas simples de JM.

4.-.1 +anejaento !e geren&iaento !e &on"ig*ra0e%

Este gerenciamento é onde descrevemos os padr(es e procedimentos !ue

devem ser usados para o gerenciamento, o conjunto de padr(es de configura'#o é o

ponto de partida para o desenvolvimento do plano.

%este plano j2 deve ser definido as responsabilidades tem !ue ser definidos

!uem ir2 entregar a cada documento ou componentes do soft$are, enfim, todos os

respons2veis, tem !ue ser definidos a!ui.

>I


20/28

>*


21/28

$ RO9R7M7ÇÃO 7R7


22/28

estendidos pelo -isL e !ue implementam padr(es de Seb service, tais comoA

-pache )andechaL !ue implementa o padr#o S):eliableMessaging, -pache

KandulaL !ue implementa os padr(es S):Joordination e S):-tomicDransaction e

-pache ampart !ue implementa o padr#o S):)ecurit.

-P-JNE JC -pache JC é um frame$orF open:source para a linguagem

Tava amplamente utili"ado pelo mercado !ue provê suporte na cria'#o e consumo

de Seb services utili"ando as especifica'(es T-:S) e T-:). -inda oferece

suporte a v2rios protocolos de mensagem e transporte.

Balani e Nathi 5L??, p. L? X Dradu'#o nossa6 afirmam !ue o JC 3é

desenvolvido com a miss#o de prover uma infraestrutura robusta para o

desenvolvimento de Seb services e facilitar o processo de desenvolvimento4. -pache JC surgiu a partir de dois projetosA Jelti e Cire e, por isso, o nome

JC. Jelti é um projeto open:source E)BL= baseado na linguagem Tava

desenvolvido pela ObjectSeb, uma empresa !ue desenvolve solu'(es open:source

de middle$are. T2 o Cire é um frame$orF open:source baseado em Tava para

desenvolvimento de Seb services baseados no protocolo )O-P desenvolvido pela

Jodehaus.

/urante as vers(es iniciais de ambos os projetos, foi constatado !ue haviamuitas caracter7sticas em comum entre eles e !ue era poss7vel transform2:los em

um 8nico projeto. - partir dessa constata'#o, foi desenvolvido com a ajuda da

-pache )oft$are Coundation, o -pache JC L.?

Outra caracter7stica importante do JC é a sua integra'#o com o )pring

frame$orF. Essa integra'#o permite utili"ar ar!uivos de configura'#o do )pring

frame$orF para !ue a publica'#o de endpoints seja feita de forma mais simples.

-pache JC conta ainda com v2rias ferramentas de apoio para odesenvolvimento de servi'os eYou consumidores. )egundo -pache JC 5L?>6,

eistem ferramentas para gera'#o de c0digo, gera'#o de documentos S)/R,

adi'#o de endpoints, gera'#o de ar!uivos de suporte e valida'#o de ar!uivos.

=.L RE76IONE OS 6USTOSA=ENE:L6IOS DE US7R FRAMEWORKS NO

DESENHOHIMENTO WEB.

L?


23/28

)e o frame$orF estiver pronto, os benef7cios s#o claros em termos deA

• edu'#o de custos

•

edu'#o de time:to:marFet

Motivo%

• Maimi"a'#o de reuso 5an2lise, design, c0digo, testes6

• /esenvolvedores se concentram em adicionar valor em ve" de reinventar a

roda

• Menos manuten'#o

• Catora'#o de aspectos comuns a v2rias aplica'(es•


24/28

• Guem pode pensar em longo pra"o !uando se est2 competindo ZOn &nternet

timeZ

•


25/28

aplica'#o 5visual6 !ue dever#o ocorrer ap0s dois anos a partir da conclus#o do

sistema é um eemploH

• estri'(es X -ssim como visto no cap7tulo anterior, as restri'(es s#o

condi'(es n#o negoci2veis !ue afetam o projeto, tais como or'amento e

cronograma.

$.4 7RUITETUR7 US7D7 E :R7ME


26/28

Entendo !ue nos sgdbsA

• /ados !ue re!uerem atuali"a'#o com n7veis finos de granularidade por

m8ltiplos usu2riosH

• /ados !ue devem ser acessados por v2rias aplica'(es

• randes !uantidades de dados !ue devem ser eficientemente manipulados

• /ados de longa dura'#o e muito valiosos a uma organi"a'#o

• /ados !ue devem ser acessados com sofisticado controle de seguran'a

• /ados sujeitos a an2lise sofisticada para o apoio 9 decis#o

Bom, como vou est2 usando a metodologia Dropos, a mesma n#o fala nada sobre a

fase de implementa'#o. %o entanto esta metodologia tem um alto refinamento do

sistema na sua fase final, teremos algumas feramentas J-)E, !ue d#o suporte a

metologia, cobrindo a fase de implementa'#o e montando o es!ueleto de c0digo

para frame$orF, como TacF, Tade, Tade, etc.

L1


27/28

( 6ON6USÃO

Este trabalho foi proveitoso no sentido de conhecer mais as

ferramentas para desenvolvimento de soft$are, projetos e ar!uiteturas, bem como o

uso de frame$orFs, e persistência de dados.

Enfim, foi um apanhado de como é criterioso e anal7tico a confec'#o

de um bom soft$are onde entendi !ue um bom soft$are tem !ue ser bem planejado

e estruturado para se tornar efica".

L=


28/28

trabalho individual v semestre

Documents