SISTEMA DE ENSINO PRESENCIAL CONECTADO CURSO SUPERIOR DE TECNOLOGIA EM ANÁLISE E

DESENVOLVIMENTO DE SISTEMAS 4º SEMESTRE

BOANERGES DE AGUIAR GOMES JÚNIOR

PRODUÇÃO TEXTUAL INTERDISCIPLINAR - INDIVIDUAL: China Telecom

PORTO VELHO

2015/1

BOANERGES DE AGUIAR GOMES JÚNIOR

PRODUÇÃO TEXTUAL INTERDISCIPLINAR - INDIVIDUAL: China Telecom

Produção Textual Interdisciplinar Individual apresentado à Universidade Norte do Paraná - UNOPAR, como componente do grau final do 4º semestre. Prof. Veronice de Freitas Marcio Roberto Chiaveli Luiz Claudio Perini

Marco Ikuro Hisatomi

PORTO VELHO 2015/1

SUMÁRIO

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

OBJETIVO .......................................... ........................................................................ 4

3 - ENGENHARIA E PROJETO DE SOFTWARE ..................................................... 4

3.1 - ÁREAS DE COMPETÊNCIA, SEGUNDO PMBOK .......................................... 4

3.1.1 - Riscos .................................... ......................................................................... 5

3.1.2 - Escopo .................................... ........................................................................ 5

3.1.3 - Fornecedores .............................. ................................................................... 6

3.1.3 - Partes Interessadas ....................... ................................................................ 7

3.2 - RESENHA DO LIVRO ENGENHARIA DE SOFTWARE .................................. 7

3.2.1 - Capítulo 11 (Projeto de Arquitetura) ...... ....................................................... 8

3.2.2 - Capítulo 12 (Arquitetura de sistemas distri buídos) .................................. 10

3.2.3 - Capítulo 13 (Arquitetura de Aplicações) ... ................................................. 12

3.2.4 - Capítulo 29 (Gerenciamento de Configurações ) ....................................... 14

4 - PROGRAMAÇÃO PARA WEB II ....................................................................... 16

4.1 - PESQUISA BIBLIOGRÁFICA SOBRE FRAMEWORKS JAVA .................... 16

4.1.1 - Comparação entre os Principais Frameworks Java ................................. 16

4.1.1.1 - Hibernate ............................... ..................................................................... 16

4.1.1.2 - Spring .................................. ....................................................................... 16

4.1.1.3 - JavaServer Faces 2 (JSF2) ............... ........................................................ 17

4.1.2 - Relação Custo/Benefício da Utilização de Frameworks ........................... 17

4.1.2.1 - Vantagens ............................... ................................................................... 17

4.1.2.2 - Desvantagens ............................ ................................................................ 17

4.1.2.3 - Conclusão ............................... ................................................................... 17

5 - PROJETO ORIENTADO A OBJETOS ........................................... .................... 17

5.1 - ARQUITETURA ................................. ............................................................... 17

5.2 - FRAMEWORK ................................... ............................................................... 18

CONCLUSÃO.......................................... ................................................................. 19

REFERÊNCIAS ........................................................................................................ 20

3

INTRODUÇÃO

Atualmente existe no mercado uma infinidade de ferramentas, padrões e guias que auxiliam as partes envolvidas no gerenciamento e no desenvolvimento de softwares.

Neste trabalho, irei realizar algumas pesquisas que envolvem o gerenciamento e desenvolvimento de sistemas, como: o Guia PMBOk e suas gerências, alguns frameworks disponíveis no mercado e plataformas de desenvolvimento web. Todas as pesquisas tem como plano de fundo o cenário proposto no trabalho, onde uma grande empresa em ascensão, a China Telecom, que está passando por um momento de transição e precisa que seus softwares eficientes e no menor tempo possível.

4

OBJETIVO

O objetivo deste trabalho é realizar um estudo sobre o uso de métodos de gerenciamento e desenvolvimento de sistemas, e algumas ferramentas como os frameworks e plataformas de desenvolvimento web.

Ao final do trabalho, o leitor:

• conhecerá algumas definições do Guia PMBOK e suas gerências; • identificará as principais características de um framework; • conhecerá as algumas etapas do desenvolvimento de um software.

3 - ENGENHARIA E PROJETO DE SOFTWARE 3.1 - ÁREAS DE COMPETÊNCIA, SEGUNDO PMBOK O guia PMBOK é um guia que contém boas práticas de gerenciamento de projetos, uma padronização das diversas teorias sobre o tema, por meio da qual são identificados todos os processos, técnicas, regras, métodos e áreas do conhecimento. Essas práticas foram identificadas de forma consensual por profissionais da área. Seu objetivo é dar bons exemplos para um melhor conhecimento do usuário. Ele introduz conceitos de gestão de projetos e, segundo o PMBOK, seguir suas técnicas de gerência aumentam as chances de êxito dos projetos.

O guia explora três conceitos principais, entre eles está o das Áreas de Conhecimento, descritas por seus requisitos de conhecimentos e termos dos processos que a compõe. A partir do Guia PMBOK 5º edição, existem dez áreas de conhecimento (o gerenciamento das partes interessadas foi introduzida na 5º

5

edição). Neste tópico será realizada uma resenha sobre quatro áreas de competência: Riscos, Escopo, Fornecedores e Partes interessadas (Stakeholders).

3.1.1 - Riscos É a área de conhecimento que aborda sobre o gerenciamento de riscos em um projeto. Seu intuito é minimizar ou eliminar a ocorrências de eventos negativos, tratando e controlando os riscos. Ela é composta por cinco processos de planejamento e um processo de controle. Os processos são:

• Planejamento do Gerenciamento de Risco: processo que define como será conduzido o gerenciamento de risco do projeto;

• Identificação dos Riscos: determina os riscos que podem afetar o projeto; • Análise Qualitativa de Riscos: este processo avalia a prioridade dos riscos

identificados; • Análise Quantitativa de Riscos: realiza a análise quantitativa dos riscos

identificados no processo anterior, analisando o efeito desses eventos de risco e classificando-os;

• Planejamento de Resposta de Risco: desenvolve ações para reduzir as vulnerabilidades encontradas no projeto;

• Monitoramento e Controle de Risco: acompanha os riscos identificados, e controla a execução de planos de respostas a riscos e avaliação da sua eficácia durante todo o ciclo de vida do projeto.

A figura 1 ilustra a sequência dos processos de gerenciamento de risco, segundo PMBOK.

Figura 1- Processos de Gerenciamento de Risco

3.1.2 - Escopo O gerenciamento do escopo compreende os processos responsáveis por manter o desenvolvimento do projeto dentro do escopo definido, garantindo o que deve e o que o que não deve estar incluído no projeto. Composto por três processos de

6

planejamento e dois processos de controle e monitoramento, como mostra a figura 2. Os processos dessa gerência são:

• Planejar o Gerenciamento do Escopo: cria um plano de gerenciamento do escopo do projeto, que documenta como tal escopo será definido e validado;

• Coletar os Requisitos: o processo de determinar, documentar e gerenciar as necessidades e requisitos das partes interessadas a fim de atender aos objetivos do projeto;

• Definir o Escopo: processo de desenvolvimento de uma descrição detalhada do projeto e do produto;

• Criar a EAP: processo de subdivisão das entregas e do trabalho do projeto em componentes menores e mais facilmente gerenciáveis;

• Validar o escopo: ocorre a formalização da aceitação das entregas concluídas do projeto;

• Controlar o Escopo: monitora o andamento do escopo do projeto e do produto e gerenciamento das mudanças feitas na linha de base do projeto.

Figura 2 - Gerenciamento do Escopo

3.1.3 - Fornecedores A gerência de aquisições descreve os processos responsáveis aquisição de produtos (compras), gerenciamento de contratos e serviços para o projeto, definindo o que se quer adquirir e de quem se quer adquirir, escolhendo o fornecedor.

É composta pelos seguintes processos:

• Planejar o gerenciamento das aquisições: neste processo, as decisões de compras do projeto são documentadas, especificando a abordagem e identificando fornecedores em potencial;

• Conduzir as aquisições: obter as respostas dos fornecedores, selecionar um fornecedor e redigir o contrato;

• Controlar as aquisições: gerencia as relações de aquisição monitorando o desempenho do contrato e realizando as mudanças e correções conforme necessário;

• Encerrar as aquisições: finalizar todas as aquisições do projeto. A figura 3 ilustra a sequência dos processos de gerenciamento de aquisições.

7

Figura 3 - Gerenciamento de Aquisições

3.1.3 - Partes Interessadas O gerenciamento foi incluído no guia PMBOK na sua 5º edição, e reforça a importância da participação de todas as das partes interessadas (stakeholders) no projeto. Uma boa interação trará um maior comprometimento, maior clareza de requisitos e objetivos, ocasionando menos mudanças no decorrer do projeto. É composto pelos seguintes processos:

• Identificar as partes interessadas: e seus interesses, envolvimento e impacto no sucesso do projeto;

• Planejar o gerenciamento das partes interessadas: desenvolver estratégias para quebrar as resistências das partes interessadas e garantir seu engajamento no projeto;

• Gerenciar o engajamento das partes interessadas: comunicar e interagir com as partes interessadas para atender suas necessidades e solucionar as questões quando ocorrem;

• Controlar o engajamento das partes interessadas: monitorar os relacionamentos entre as partes interessadas e ajustar as estratégias para engajar as partes interessadas eliminando resistências e aumentando o suporte ao projeto.

3.2 - RESENHA DO LIVRO ENGENHARIA DE SOFTWARE De acordo com o cenário proposto, a empresa China Telecom decidiu investir em um software de ERP fornecido por uma empresa de renome do que investir no

desenvolvimento interno, com a justificativa de que levaria muito tempo e sairia muito caro desenvolver um software. O desafio 2 propõe um cenário diferente, onde a empresa decide pelo desenvolvimento próprio, e uma resenha dos seguintes

8

capítulos 11, 12, 13 e 29 do livro Engenharia de Software, de Ian Sommerville, 8º edição.

3.2.1 - Capítulo 11 (Projeto de Arquitetura) O projeto de arquitetura é primeiro estagio no processo de projetos.

No livro diz que ele idêntica subsistemas e estabelece um framework para controlar a comunicação dos subsistemas, também representa uma ligação critica entre processos de engenharia de projeto e requisitos.

Três vantagens de projetar e documentar explicitamente uma arquitetura de software: Comunicação de stakeholders, Analise de sistemas, Reuso em larga escala:

A arquitetura de software serve para negociar requisitos de sistema e estruturar discussões com os clientes, desenvolvedores e gerentes. É uma ferramenta essencial parra gerenciamento de complexidade, ocultando detalhes e focando as abstrações principais do sistema.

Se o desempenho for um requisito crítico a aplicação deve localizar operações criticas dentro de subsistemas e usar componentes de alta granularidade em detrimento dos de baixa granularidade para reduzir a comunicação entre eles.

Se a facilidade de manutenção for um requisito crítico, a arquitetura de sistemas deve ser projetada usando componentes de baixa granularidade e auto contidos que possam ser prontamente mudados.

Um projeto de subsistemas é decomposição abstrata de um sistema de componentes em alta granularidade. Os diagramas de blocos são usados para representar um projeto de subsistemas.

Esses diagramas de blocos são bons para comunicação entre stakeholders e para o planejamento do projeto pois não estão abarrotados de detalhes, já para a arquitetura não são tão bons, pois não mostram relacionamento entre os componentes do sistema.

Um modelo estático de estrutura que mostra os subsistemas ou componentes desenvolvidos como unidades separadas.

Um modelo dinâmico de processo que mostra como o sistema esta organizado em processos em tempo de execução.

A organização de um sistema reflete a estratégia básica usada para estruturá-lo. Você precisa tomar decisões sobre o modelo geral organizacional de um sistema com antecedência no processo de projeto de arquitetura. A organização pode refletir diretamente na estrutura do subsistema.

Em um modelo de arquitetura cliente – servidor é um modelo em que o sistema é organizado como um conjunto de serviços e servidores e clientes associados que acessam e usam os serviços. Os clientes talvez precisem saber os nomes dos servidores disponíveis e os serviços que eles fornecem.

9

A vantagem de um modelo cliente servidor é que ele é uma arquitetura distribuída. O uso efetivo de sistemas em rede pode ser feito com muitos processadores distribuídos. É fácil adicionar um novo servidor e integrá-lo ao restante do sistema.

O modelo em camadas organiza um sistema em camadas, cada uma das quais fornecendo um conjunto de serviços.

A abordagem em camadas apóia o desenvolvimento incremental de sistemas. A medida que uma camada é desenvolvida alguns serviços fornecidos por essa camada podem ser disponibilizados para os usuários. Essa arquitetura também é modificável e portável.

Uma desvantagem da abordagem em camadas é que a estruturação de sistemas dessa maneira pode ser difícil. As camadas mais internas podem fornecer recursos básicos, como gerenciamento de arquivos, necessários em todos os níveis.

Depois que a organização geral do sistema foi escolhida, precisa-se tomar uma decisão sobre a abordagem a ser usada na decomposição de subsistemas em módulos.

Um modulo é normalmente um componente de sistema que fornece um ou mais serviços para outros módulos. Ele faz uso de serviços fornecidos por outros módulos.existem duas estratégias principais que você pode usar ao decompor um subsistema em módulos.

No pipelining orientado a funções ou modelo de fluxo de dados, as transformações processam suas entradas e produzem saídas. Os dados fluem de uma para outra função e são transformados ao moverem – se seqüencialmente. Cada etapa é implementada como uma transformação.

Os dados de entrada fluem através dessas transações ate serem convertidos em dados se saída. Vantagens: Apoiar o reuso de transformações.

Ele é intuitiva, pois muitas pessoas pensam em termos de processamento de entrada e saída.

Os modelos de controle tem como objetivo controlar subsistemas de maneira que seus serviços sejam entregues no lugar certo e no tempo certo.

Modelos de controle são usados em conjunto com estilos de estrutura. Todos os estilos 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 sistema e tem a responsabilidade pelo gerenciamento da execução de outros subsistemas. Tendo duas classes, dependendo se forem executados seqüencialmente ou paralelamente.

O modelo retorno começa no topo da hierarquia de sub – rotina e, através de chamadas de sub-rotinas, passa para os níveis mais baixos na arvore, são aplicados em modelos seqüenciais.

10

O modelo gerenciados, aplicados em modelos concorrentes. Sistema concorrente projetado como um gerenciador de sistema e controla o inicio, a parada e a coordenação de outros processos do sistema.

As arquiteturas de referencia não são geralmente consideradas um roteiro de implementações. Em vez disso, sua principal função é ser um meio de discussão de arquiteturas de domínio especifico e de comparação de sistemas diferentes em um domínio.

Uma proposta de modelo de referencia é um modelo para ambientes CASE que identifica cinco conjuntos de serviços que um ambiente CASE deve fornecer. Ele deve também fornecer recursos de plug-in para ferramentas CASE individuais que usam esses serviços.

A finalidade dessa arquitetura de referencia é ser um meio de classificação e comparação de ferramentas e ambientes CASE integrados.

3.2.2 - Capítulo 12 (Arquitetura de sistemas distri buídos)

Um sistema bem distribuído é aquele em que as informações em fase de processamento são distribuídas a vários computadores.

Vantagens de usar uma abordagem distribuída para desenvolvimento de sistemas: Compartilhamento de recursos, Abertura, Concorrência, Escalabilidade, Tolerância a defeitos.

Esses sistemas de distribuição comparados aos sistemas que operam com um processador ou com um cluster de processadores podem ter algumas desvantagens como: Complexidade, Proteção, Gerenciamento, Imprevisibilidade e Defeitos que em uma maquina podem se propagar a outra maquinas com conseqüências inesperadas.

Tipos diferentes de arquiteturas de sistemas distribuídos:

• Arquitetura cliente-servidor. É o sistema como um conjunto de serviços fornecidos aos clientes que fazem uso desses serviços. Os servidores e clientes são tratados de maneiras diferentes nesses sistemas.

• Arquiteturas de objetos distribuídos. Podemos pensar no sistema como um conjunto de objetos que interagem e cuja a localização é irrelevante. Não há distinção entre cliente e servidor.

Tanto a arquitetura cliente-servidor e a arquitetura de objetos distribuídos são amplamente usadas no setor, mais a aplicação ocorre geralmente dentro de uma única organização. A organização é, portanto, intra-organizacional.

Arquitetura de multiprocessadores

11

O multiprocessador São processos que podem ser executados separados. Esse modelo tomam decisões usando essas informações e enviam sinais aos atuadores, que modificam o ambiente do sistema. O uso de vários processadores aprimora o desempenho e a capacidade de recuperação do sistema

Arquiteturas de objetos distribuídos

Nesse modelo os objetos podem ser distribuídos entre uma serie de computadores na rede e se comunicam através de um middleware, que é chamado de requisitor de objetos. O Middleware fornece uma interface transparente continua entre os objetos. Ele fornece um conjunto de serviços que permitem que os objetos se comuniquem e sejam adicionados e removidos do sistema. As vantagens são:

Permite que o projetista do sistema postergue decisões sobre onde e como os serviços devem ser fornecidos.

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

Uma arquitetura de objetos distribuídos pode ser usada como um modelo lógico, que permite estruturar e organizar o sistema.

Uma arquitetura de objetos distribuídos em lugar de uma arquitetura cliente-servidor é adequada para esse tipo de aplicação por três razões:

O modelo lógico do sistema não é um dos fornecimentos de serviços em que existem serviços distintos de gerenciamento de dados. Pode adicionar bancos de dados ao sistema sem grande interrupções.

A maior Desvantagem é que elas são mais complexas do que sistemas cliente-servidor.

CORBA Existem quatro elementos principais desse padrão:

• Um modelo de objeto para objetos de aplicações.

• Um requisitor de objetos.

• Um conjunto de serviços de objetos. • Um conjunto de componentes comum.

O Corba considera um objeto como se fosse um encapsula mento de atributos e serviços, como é normal em objetos.

Os objetos corba tem um único identificador chamado de referencia de objeto interoperavel. Esse IOR é usado quando um objeto solicita serviços de um outro objeto.

O requisitor de objetos conhece os objetos que estão solicitando serviços e suas interfaces. O ORB cuida da comunicação entre os objetos.os objetos que se comunicam não precisam conhecer a localização de outros objetos nem sobre sua implementação.

12

O objeto que fornece o serviço tem um esqueleto de IDL associado que liga a interface a implementação dos serviços.

Os padrões Corba incluem definições de interface para uma grande variedade de componentes horizontais e verticais. Os componentes verticais são componentes específicos de um domínio de aplicação. Os componentes horizontais são componentes de propósito geral, como componentes de interface com o usuário.

Por motivo de segurança e interoperabilidade, a computação distribuída foi implementada inicialmente em nível organizacional. Uma organização tem uma serie de servidores e distribui sua carga computacional entre eles. Devido ao fato de eles estarem todos localizados dentro da mesma organização, podem ser aplicados padrões e processos operacionais locais.

A essência de um serviço, é que o fornecimento dos serviços é independente da aplicação que usa o serviço. Os provedores de serviços podem desenvolver serviços especializados e oferecê-los a uma gama de usuários de serviços de organizações diferentes.

A proposto WEB Service foi lançada pois o acesso de servidores web, era somente por meio de navegar web, e o acesso direto aos repositórios de informações por outros programas não era pratico.

Os três padrões fundamentais que possibilitam comunicação entre WEB SERVICES são:

• SOP - Define uma organização para troca estruturada de dados entre WEB SERVICES.

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

• UDDI - Este é um padrão de descobrimento que define como as informações de descrição do serviço usadas pelos solicitantes do serviços para descobrir serviços, pode ser organizada.

Todos estes padrões baseados em XML.

3.2.3 - Capítulo 13 (Arquitetura de Aplicações)

Aplicações de processamento de dados.

São Aplicações voltados a dados. Elas Processam dados em lotes sem intervenções explicitas do usuário durante o processamento. As Ações explicitas tomadas pela aplicação dependem dos dados que são processados.

Os sistemas de processamento em lotes são normalmente usados em aplicações de negócios nas quais as operações similares são realizadas sobre uma grande quantidade de dados.

Eles tratam de uma grande variedade de funções administrativas, como folha de pagamento, cobrança, contabilidade e publicidade. Essas aplicações enfocam os

13

dados. Os bancos de dados são geralmente maiores que os sistemas de informações (SI).

Os sistemas de processamento de dados selecionam os dados de registros de entrada e, dependendo do valor dos campos nos registros, tomam algumas ações especificadas no programa. Eles podem, então, enviar o resultado novamente do processamento ao banco de dados e formatar a entrada e a saída processada para impressão.

Os sistemas de transações são projetados para processar solicitações de informações por usuários de um banco de dados. Tecnicamente uma seqüência de operações é tratada como uma unidade simples.

Todas as operações tem que ser realizadas antes que as mudanças tornem-se permanentes no banco de dados. Os sistemas de processamento de transações são geralmente sistemas interativos nos quais os usuários enviam solicitações assíncronas de serviço.

Primeiro um usuário faz uma solicitação para o sistema através de um componente de processamento de entrada/saída. A solicitação é processada por alguma lógica especifica da aplicação.

Uma transação é criada e passada para um gerenciador de transações, que é em geral incorporado ao sistema de gerenciamento de banco de dados. Depois que o gerenciador de transações assegurar que a transação foi concluída adequadamente, ele sinalizara para a aplicação que o processamento foi finalizado.

A estrutura entrada-processo-saída se aplica aos muitos sistemas de processamento de transações. Alguns desses sistemas são versões interativas de sistemas de processamento de lotes.

Em sistemas como os de contabilidade de clientes de um banco, pode haver diferentes maneiras de interagir com o sistema. Muitos clientes interagirão por meio de caixas eletrônicos, mas uma equipe do banco usara terminais de mesa para acessar o sistema. Pode haver vários tipos de caixas eletrônicos e terminais de mesa, e alguns clientes e a equipe do banco podem acessar os dados de contas por meio de navegadores WEB.

Os sistemas de processamento de linguagens aceitam uma linguagem natural ou artificial como entrada e geram alguma outra representação dessa linguagem como saída.

Em engenharia de software, os sistemas de processamento de linguagens mais amplamente usados são os compiladores que traduzem uma linguagem artificial de programação de alto nível em código de maquina. Mais outros sistemas de processamento de linguagens traduzem uma descrição 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 genérica que inclui os seguintes componentes:

14

Um analisador léxico, uma tabela de símbolos, um analisador sintático, uma árvore de sintaxe, um analisador semântico e um gerador de código.

3.2.4 - Capítulo 29 (Gerenciamento de Configurações )

Gerenciamento de configurações é o desenvolvimento e o uso de padrões e procedimentos para o gerenciamento de sistemas de software em desenvolvimento. Ha muitas razões por que os sistemas existem em diferentes configurações.

Configurações podem ser produzidas para diferentes computadores, diferentes sistemas operacionais, incorporando funções especificas para clientes.

Os gerentes de configurações são responsáveis por manter a rastreabilidade das diferenças entre versões de software, para assegurar que as novas versões sejam derivadas de maneira controlada e liberar novas versões para clientes certos no momento certo.

O plano de gerenciamento de configurações descreve os padrões e procedimentos que devem ser usados para o gerenciamento. O ponto de partida para o desenvolvimento do plano deve ser um conjunto de padrões de configuração, que devem ser adaptados para se atender aos requisitos e as restrições de cada projeto específico.

Em um grande sistema de software, pode haver módulos de milhares de códigos fonte, scripts de testes, documentos de projeto etc. Eles são produzidos por pessoas diferentes e, quando criados, podem ser denominados com nomes similares ou idênticos. Para manter a rastreabilidade de todas essas informações de maneira que o arquivo certo possa ser encontrado quando for necessário você necessita de um esquema de identificação consistente para todos os itens no sistema de gerenciamento de configurações.

Planos de projetos, especificações, projetos, programas, e massa de dados de teste são normalmente mantidos como itens de configuração para o processo de planejamento de gerenciamento de configuração, você decide exatamente quais itens serão controlados.

Todos os documentos podem ser úteis para a evolução do sistema. O esquema de identificação de itens de configuração deve atribuir um único nome para todos os documentos sob controle de configuração. No esquema de atribuição de nomes, você pode desejar evidenciar a relação entre os itens para garantir que os documentos relacionados possuam uma mesma raiz em seus nomes.

O banco de dados de configuração é utilizado para registrar todas as informações relevantes sobre as configurações de sistema e os itens de configuração. Como parte do processo de CM, deve-se definir o esquema do banco de dados de CM, os formulários para coletar informações para serem registradas no banco de dados e procedimentos para registro e recuperação de informações de projeto.

15

Um banco de dados de configuração pode registrar informações sobre usuários de componentes, clientes de sistemas, plataformas de execução, mudanças propostas e etc.

De preferência, um banco de dados de configuração deve ser integrado com a versão do sistema 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 mudanças correspondentes no sistema de software.

Para garantir que essas mudanças serão aplicadas ao sistema de maneira controlada, você precisa de um conjunto de procedimentos de gerenciamento de mudanças apoiado por ferramentas.

O primeiro estágio no processo de gerenciamento de configurações é completar um formulário de solicitação de mudança (CRF – change request form) que descreve a mudança necessária para o sistema. Uma vez que o formulário de solicitação de mudança é enviado, ele deve ser registrado no banco de dados de configuração. A solicitação de mudança é então analisada para verificar se a mudança solicitada é necessária.

Para mudanças validas, o estagio seguinte é a avaliação da mudança e o custo. Se realizar a mudança significa que mudanças adicionais em alguma parte do sistema são necessárias, isso aumenta claramente o custo de sua implementação.

Em seguida as mudanças necessárias para os módulos do sistema são avaliadas. Finalmente, o custo para realizar a mudança é estimado, considerando os custos de mudança nos componentes relacionados.

Para criar uma versão especifica de um sistema, você precisa especificar as versões dos componentes de sistema que devem ser incluídas nele. Você não pode usar o nome do item de configuração para identificar a versão, porque ele pode ter muitas versões para cada item de configuração identificado.

Uma das três técnicas básicas para identificação da versão de componentes é Numeração de versões. O componente recebe um numero explicito e único de versão. Isso é o mais comumente usado no esquema de identificação.

"A versão de componente é identificada pelo conjunto de solicitações de mudanças que se aplicam ao componente."

Processos de gerenciamento de configurações são normalmente padronizados e envolvem aplicações de procedimentos predefinidos. Eles requerem o gerenciamento cuidadoso de grande quantidade de dados e é essencial a atenção aos detalhes.

Quando um sistema está sendo construído com base em versões de componentes, um único erro de gerenciamento de configuração pode significar que o software não irá operar adequadamente.

16

Conseqüentemente, o apoio de um ferramenta CASE é essencial para o gerenciamento de configuração. Essas ferramentas podem ser combinadas para criar uma área de trabalho para apoiar todas as atividades de CM.

4 - PROGRAMAÇÃO PARA WEB II 4.1 - PESQUISA BIBLIOGRÁFICA SOBRE FRAMEWORKS JAVA A linguagem Java apresenta uma grande variedade de frameworks que auxiliam no desenvolvimento de sistemas. Oferecem ao programador um conjunto de códigos prontos que permitem realizar as tarefas mais básicas no desenvolvimento de um aplicativo. Para a orientação a objeto, um framework é um conjunto de classes com objetivo de reutilização de um design, provendo um guia para uma solução de arquitetura em um domínio específico de software. A reutilização de códigos de um framework proporciona ao desenvolvedor uma solução rápida para problemas comuns.

4.1.1 - Comparação entre os Principais Frameworks Java Como mencionado anteriormente, a linguagem Java possui uma grande variedade de frameworks. Dentre eles destaco:

4.1.1.1 - Hibernate

Hibernate é um framework de persistência utilizado para o mapeamento objeto-relacional. Ele facilita o mapeamento dos atributos entre uma base tradicional de dados relacionais e o modelo objeto de uma aplicação. O objetivo do Hibernate é diminuir a complexidade entre os programas Java, baseado no modelo orientado a objeto, que precisa trabalhar com um banco de dados do modelo relacional.

Sua principal característica é a transformação das classes em Java para tabelas de dados (e dos tipos de dados Java para os da SQL). O Hibernate gera as chamadas SQL e libera o desenvolvedor do trabalho manual da conversão dos dados resultante, mantendo o programa portável para quaisquer bancos de dados SQL, porém causando um pequeno aumento no tempo de execução.

4.1.1.2 - Spring Sendo um dos mais utilizados em projetos Java, o Spring é um framework open source para a plataforma Java de inversão de controle (Inversion of Control ou IoC), também chamado de container. Nele o container se encarrega de "instanciar" classes de uma aplicação Java e definir as dependências entre elas através de um arquivo de configuração em formato XML, inferências do framework ou ainda anotações nas classes, métodos e propriedades.

17

4.1.1.3 - JavaServer Faces 2 (JSF2) Com muitas melhorias em relação a sua versão anterior (JSF1.2) o JFS2 é um framework MVC (Model-view-controller, que é um padrão de arquitetura de software que separa a representação da informação da interação do usuário com ele.) de teste para a construção de interfaces de usuário baseadas em componentes para aplicações web. Possui um modelo de programação dirigido a eventos, abstraindo os detalhes da manipulação dos eventos e organização dos componentes, permitindo que o programador se concentre na lógica da aplicação.

4.1.2 - Relação Custo/Benefício da Utilização de Frameworks O desenvolvimento de aplicações web utilizando frameworks se expandiu de tal forma que tornou-se imprescindível seu uso para construção de sistemas voltados para internet. Existem inúmeros benefícios, como ganho de produtividade e e integração entre aplicações, mas também alguns desvantagens.

4.1.2.1 - Vantagens • Redução de custos; • Redução do tempo;

4.1.2.2 - Desvantagens • Reuso não vem sozinho: deve ser planejado; • Frameworks provocam perda de desempenho, mas isso geralmente é

imperceptível; • Se um framework tiver uma falha de segurança, a aplicação fica vulnerável.

4.1.2.3 - Conclusão Hoje em dia, dificilmente alguém consegue levantar argumentos válidos contra o uso de frameworks web, os benefícios de sua utilização superam muito as possíveis desvantagens da sua utilização.

5 - PROJETO ORIENTADO A OBJETOS

5.1 - ARQUITETURA

Para o cenário proposto da empresa China Telecon, uma solução viável para desenvolver o software para em questão seria utilizar a arquitetura MVC (Model-view-controller) em português modelo-visão-controlador , é um padrão de

18

arquitetura de software que separa a representação da informação da interação do usuário com ele.

A arquitetura MVC foi criada na década de 70, e após esses anos de sua criação ainda é um pattern aplicável nas mais variadas aplicações, principalmente em aplicações web.

O MVC tem como principal objetivo separar dados ou lógicos de negócios (Model) da interface do usuário (View) e o fluxo da aplicação (Controller), a ideia é permitir que uma mensagem da lógica de negócios pudesse ser acessada e visualizada através de várias interfaces. Na arquitetura MVC, á lógica de negócios, ou seja, nosso Model não sabe quantas nem quais as interfaces com o usuário esta exibindo seu estado, a view não se importa de onde esta recebendo os dados, mas ela tem que garantir que sua aparência reflita o estado do modelo, ou seja, sempre que os estados do modelo mudam, o modelo notifica as view para que as mesmas atualizem-se.

MVC é um conceito (paradigma) de desenvolvimento e design que tenta separar uma aplicação em três partes distintas. Uma parte, a Model, esta relacionada ao trabalho atual que a aplicação administra outra parte a View esta relacionada a exibir os dados ou informações dessa uma aplicação e a terceira parte, Controller, em coordenar os dois anteriores exibindo a interface correta ou executando algum trabalho que a aplicação precisa completar.

Embora o MVC só contenha três camadas, há outra camada fundamental para o bom andamento da arquitetura. Esta é um mecanismo de eventos necessário a comunicação entre outros três elementos, este elemento permite uma comunicação assíncrona que é invocada quando algum evento interessante acontece, esta quarta camada contém os beans de entidade onde se localizam os métodos get e set das classes.

5.2 - FRAMEWORK

Uma das melhores opções seria o Hibernate como framework de persistência de dados. O Hibernate é um framework para mapeamento objeto/relacional em Java, que abstrai o código SQL da aplicação, permitindo, entre outra coisas, modificar a base de dados para outro SGBD (Sistema Gerenciador de Banco de Dados) sem modificar uma linha de código.

19

CONCLUSÃO O trabalho foi realizado respeitando o contexto do cenário proposto, onde uma grande empresa em ascensão, a China Telecom, que está passando por um momento de transição e precisa que seus softwares eficientes e no menor tempo possível.

Realizar esta atividade foi muito construtiva para meu desenvolvimento acadêmico, pois durante a pesquisa realizada foi possível aprender conceitos importantes sobre Guia PMBOK, suas regras e práticas; sobre os frameworks disponíveis no mercado e suas aplicabilidades e os modelos de arquitetura.

20

REFERÊNCIAS

Sommerville, Ian. Engenharia de Software, 9ª Edição. Pearson Education, 2011.

Sommerville, Ian. Engenharia de Software, 8ª Edição. Pearson Education, 2009.

TANAKA, Simone Sawasaki. Análise de Sistemas II. Pearson Education, 2009.

RAMOS, José Yoshiriro Aijisaka. Comparação entre os principais Frameworks Java para o desenvolvimento de aplicações WEB 2.0

PAES, Luiz Alberto Bertolucci. A Utilização da Metodologia PMBOK no Gerenciamento de projetos: Uma Análise das Novas Práticas propostas na 5º Edição. Disponível em: http://revista.univem.edu.br/index.php/REGRAD/article/viewFile/764/361. Acesso em 03.05.15.

http://www.portal-administracao.com/2014/01/entendendo-o-guia-pmbok.html. Acesso em: 05.05.15.

http://www.portal-administracao.com/2014/06/areas-do-conhecimento-guia-pmbok.html. Acesso em: 08.05.15.

http://www.diegomacedo.com.br/gerenciamento-do-escopo-do-projeto-pmbok-5a-ed/?print=print . Acesso em: 10.05.15.