Trabalho de individual

Prévia do material em texto

�PAGE �
SUMÁRIO
31 INTRODUÇÃO	0�
42 DESENVOLVIMENTO	0�
CONCLUSÃO.........................................................................................................................21
REFERENCIA........................................................................................................................22
��
INTRODUÇÃO
A produção textual que será desenvolvida estará baseando se em um estudo de caso da Empresa China Telecom que trabalha no ramo de Telefonia
Falaremos sobre engenharia e projeto de software aprofundará o conhecimento das aulas adquiridas no decorrer do semestre mostraremos alguns princípios básicos para que se desenvolva uma aplicação mais segura.
DESENVOLVIMENTO
2.1. Engenharia e Projetos de Software
Desafio 1
O desenvolvimento de software é uma atividade complexa envolvendo inúmeros fatores que são imprevisíveis e de difícil controle, como inovações tecnológicas e mudanças constantes nos requisitos do cliente, dentre muitos outros. Esta complexidade faz com que grande parte dos projetos de desenvolvimento de software exceda o prazo e o orçamento previstos, além de não atender à s expectativas do cliente em termos de funcionalidades e qualidade. Diante deste cenário, um gerenciamento eficaz tem - se evidenciado como de fundamental importância para o sucesso de projetos de software. 
O objetivo da fase de Elaboração é eliminar os principais riscos e estabelecer uma arquitetura estável a partir da qual o sistema poderá evoluir. Na fase de Construção, um produto completo é desenvolvido de maneira iterativa até que esteja pronto para ser passado aos usuários, o que ocorre na fase de Transição, onde uma versão beta do sistema é disponibilizada. Cada fase pode comportar várias iterações e cada iteração, por sua vez, está organizada em disciplinas, que descrevem o que deve ser feito em termos de atividades, responsáveis e artefatos. RUP (2003).
O desenvolvimento de software tem avançado tecnologicamente em rápidas proporções, mas existem fatores que ocorrem desde o começo desse avanço, são eles: os erros de gestão e a falta de sucesso do software desenvolvido, muitas vezes não atendendo o que cliente desejava. Para o sucesso ser completo, o produto final deve ser entregue dentro do prazo, com o custo especificado, e ser realmente aquilo que o cliente necessitava. 
A Gerência de Projetos é uma solução para os problemas que as equipes de desenvolvimento de Software vem enfrentando, porque é distribuída em áreas de conhecimento, onde cada uma delas descreve seus respectivos processos a fim de garantir que os objetivos planejados sejam atingidos. As técnicas de gerenciamento de projetos estão sendo aprimoradas constantemente, buscando sempre garantir o sucesso dos processos. 
O Project Management Body of Knowledge, também conhecido como PMBOK é um conjunto de práticas em gerência de projetos levantado pelo Project Management Institute (PMI) e constituem a base da metodologia de gerência de projetos do PMI. Estas práticas são compiladas na forma de um guia, chamado de Guia do Conjunto de Conhecimentos em Gerenciamento de Projetos, ou Guia PMBOK. (ALENCAR, 2006) 
O Gerente de projetos é a pessoa responsável pela realização dos objetivos do projeto, identificando às necessidades, estabelecendo objetivos claros e possíveis de ser alcançados e tentar equilibrar qualidade, escopo, tempo e custo, a ainda atender às expectativas das partes interessadas no projeto. Ele e sua equipe deverão seguir um código de ética e conduta profissional para aqueles que possuem a certificação PMP. 
No gerenciamento de projetos são aplicados os conhecimentos, habilidades, ferramentas e técnicas às atividades do projeto e é realizado através da aplicação e da integração das seguintes áreas de competências gerências, são elas: Gerenciamento de Integração, Gerenciamento de Escopo, Gerenciamento de: Tempo; do Custo; da Qualidade; dos Recursos Humanos; da Comunicação; de Aquisições e Gerência de Riscos. (PMI, 2004; DINSMORE, 2005; GURGEL, 2007)
O objetivo principal do Gerenciamento de Escopo é definir e manter o desenvolvimento do projeto dentro do escopo desenhado, controlando o que deve e o que não deve estar incluído no projeto, tendo a segurança, que é realmente a necessidade do cliente, e qualquer mudança que venha a se realizar no escopo deverá ter o consentimento do cliente.
Já a Gerência de Risco é o objeto de estudo da monografia e será detalhado no próximo capítulo. O objetivo principal dessa gerência é maximizar os resultados de ocorrências positivas e minimizar as consequências negativas ou até mesmo eliminar eventos adversos, tratando e controlando os riscos.
Desafio 2
A arquitetura deve ser escolhida a partir dos requisitos não funcionais do sistema. 
• Se o desempenho for um requisito critico a arquitetura deve ser projetada para encontrar operações criticas dentro de alguns subsistemas.
• Se a proteção for um requisito critico, deve ser utilizada uma estrutura por camas, assim protegendo os itens mais críticos.
• Se a segurança for um requisito critico, a arquitetura deve ser projetada, fazendo com que todas as operações relacionadas a segurança, devem estar localizada em um subsistema, ou em poucos subsistemas.
• Se a disponibilidade for um requisito critico, a arquitetura deve ser projetada utilizando componentes que podem ser substituídos e atualizados sem dificuldades.
• Se a facilidade de manutenção for um requisito critico, a arquitetura deve ser projetada usando componentes de baixa granularidade e auto contidos que possam ser prontamente mudados.
Porem existe conflitos entre as arquiteturas adotadas, já que algumas exigem o uso de componentes opostos, como é o caso de componentes de alta e baixa granularidade, quando existe este conflito, deve ser proposto uma solução eficaz, pode-se conseguir isso, algumas vezes, pelo uso de estilos de arquiteturas diferentes para cada parte do sistema.
O Projeto de um subsistema é uma decomposição abstrata de um sistema em componentes, cada um podendo ser um sistema substancial e independente, para um projeto de subsistema é utilizado o diagrama de blocos. Caixas dentro de caixas indicam que o subsistema foi ele próprio decomposto em subsistemas. As setas são utilizadas para indicar fluxo de dados e sinais de controle. Este diagrama deve ser utilizado de forma que pessoas de áreas diferentes envolvidas no mesmo processo de desenvolvimento do sistema possam entender.
De acordo com Bass (2007), este diagrama de caixas em linhas não são representações úteis de arquitetura, já que não mostram a natureza dos relacionamentos entre componentes do sistema. Porem este modelo é eficaz para comunicação com os stakeholders do sistema e para planejamento do sistema, pois ele é simples e não tem muitos detalhes. O diagrama de caixas e linhas não pode ser a única representação de arquitetura a ser utilizada em um projeto.
A dificuldade em descompor um sistema em subsistemas é que os requisitos do sistema são um fator principal e o projeto deve ter uma correspondência estrita entre os requisitos e os subsistemas, e durante um projeto, os requisitos mudam, porem os subsistemas não.
Projeto de arquitetura é um processo que tenta estabelecer uma organização de sistemas que satisfaça os requisitos funcionais e não funcionais do sistema. Para definir qual arquitetura devem ser utilizados, os arquitetos de sistema tentam responder as seguintes questões.
1. Existe uma arquitetura genérica de aplicação que possa funcionar como modelo para o sistema que está sendo projetado?
2. Como o sistema será distribuído ao longo de vários processador?
3. Qual ou quais estilos de arquitetura são apropriados para o sistema?
4. Qual será a abordagem fundamental para estruturar o sistema?
5. Como as unidades estruturais de um sistemaserão descompostas em módulos?
6. Qual estratégia será usada para controlar a operação das unidades do sistema?
7. Como o projeto de arquitetura será avaliado?
8. Como a arquitetura deve ser documentada?
Mesmo cada sistema de software seja único, frequentemente sistemas que de mesmo domínio de aplicação tem arquitetura similares, assim tornando algumas arquiteturas bastante genéricas.
Dependendo do sistema, seja ele pequeno, somente para um único processador, ou para um sistema que vai ser distribuído em vários processadores, à escolha da arquitetura de distribuição é muito importante pois afeta no desempenho e confiabilidade do sistema.
A arquitetura de um sistema de software pode ser baseada em um modelo ou estilo de arquitetura, saber os pontos fortes e fracos de cada estilo é importante, porem não é obrigatório que todo o sistema siga somente um estilo, assim podendo utilizar uma arquitetura composta criada pela combinação de diferentes estilos.
Você precisa escolher a estrutura mais apropriada para atender os requisitos do sistema. Para avaliar esta estrutura é difícil, pois o verdadeiro teste de arquitetura recai sobre quão bem elas atendem os requisitos. Contudo você pode comparar o seu projeto, como modelos genéricos de arquitetura.
A organização de um sistema é a estratégia básica usada para estruturá-lo, pode refletir diretamente na estrutura do subsistema. Nessa seção é explicada três estilos de organizações. Estes podem ser utilizados separadamente ou juntos.
Modelo Repositório
Os subsistemas devem trocara informações para trabalharem juntos eficientemente. Pode ser feito de duas maneiras, todos os dados são compartilhados no mesmo banco de dados para que possam ser acessados de qualquer subsistema, ou os dados podem ser mantidos em bancos de dados separados, e estes são trocados entre os subsistemas por meio de mensagens.
A maioria dos sistemas com grande quantidades de dados são organizados em um único banco de dados compartilhado. Este modelo é adequado para aplicações que os dados são gerados por um subsistema, e utilizado por outro.
Modelo Cliente-Servidor
Neste modelo o sistema é organizado como um conjunto de seriações e servidores, e os clientes acessam os servidores para utilizar os serviços. Os clientes talvez precisem saber os nomes dos servidores disponíveis e os serviços que eles fornecem,porem os servidores não precisam saber quem é, ou quantas são os clientes que existem. Neste modelo o cliente faz o pedido para o servidor, e aguarda uma resposta.
Modelo em camadas.
Neste modelo a arquitetura é organizada de maneira que cada camada fornece um conjunto de serviços. Este modelo apoia o desenvolvimento incremental de sistemas, quando uma camada é desenvolvida alguns serviços desta camada podem ser disponibilizados para os usuários, este modelo também é fácil de ser modificado e também é portátil, desde que sua interface permaneça inalterada, uma camada poderá ser substituída por outra equivalente. Além disso, quando as interfaces de camada são alterada, ou novos recursos são adicionados a uma cada, somente a cama adjacente é afetada.
Depois que é definido um modelo de organização, deve se decidir como será feita a abordagem a ser usada na decomposição dos subsistemas em módulos. Em uma abordagem orientada a objetos, os módulos são objetos com estado privado e operações definidas, já no modelo de pipelining os módulos são transformações funcionais. Em ambos os casos, os módulos podem ser implementados como componentes ou processos sequenciais.
Decomposição orientada a objeto
Um modelo de arquitetura orientada a objetos estrutura o sistema em um conjunto de objetos não firmemente acoplado com interfaces bem definidas. Os objetos chamam serviços oferecidos por outro objeto.
As vantagens da decomposição orientada a objeto, por não serem firmemente acoplados eles são facilmente modificados sem afetar outro objeto, e também por os objetos serem representações de entidades do mundo real, são facilmente compreendidos. Porem ele também tem suas desvantagens, para um objeto usar os serviços de outro, devem fazer referencia explicita ao nome e a interface dos outros objetos, se uma mudança de interface for necessária, devem ser mudadas todas as referencias também.
Pipelining orientado a funções
Neste modelo de fluxo de dados, é feito o processamento dos dados que entram, e é produzido os dados que saem. Os dados fluem de maneira linear de uma função, para a outra, e são transformados neste meio tempo.
Vantagens
• Apóia o uso de transformações.
• É intuitiva no sentido que muitas pessoas pensam em seu trabalho em termos de processamento de entrada e saída.
• A evolução do sistema pela adição de novas transformações é geralmente direta.
• Simples de ser implementada tanto quanto um sistema concorrente ou sequencial.
Modelos de controle é a maneira que os subsistemas devem ser controlados para formar um sistema completo. Existem dois estilos genéricos de controle usados em sistema de software.
Controle centralizado
Neste modelo, um subsistema é designado para controlar o sistema e tem como responsabilidade o gerenciamento da execução de outros subsistemas. Existem dois modelos de controle centralizado.
1. Modelo chamada - retorno, este modelo é conhecido como modelo top - down de sub-rotina em que o controle começa no topo da hierarquia e termina nos níveis mais baixos.
2. Modelo gerenciador, este modelo é aplicável a sistemas concorrente, um processo é um subsistema ou um modelo que precisa ser executado paralelamente.
Sistema orientado a eventos
Este modelo é regido pelos eventos gerados externamente, um evento sempre é chamado dependendo da ação executada na interface. Este modelo é muito utilizado em ferramentas de edição, sistemas de I.A, entre outros.
Diferente de aguardar por um comando completo que processa a informação, o sistema em tal paradigma é programado em sua base em um laço de repetição de eventos, que recebem repetidamente informação para processar e disparam uma função de resposta de acordo com o evento.
O método pelo qual a informação é adquirida por camadas mais baixas do sistema é irrelevante. As entradas podem ser enfileiradas ou uma interrupção pode ser registrada para reagir, ou ainda ambos.
Programas orientados a evento geralmente consistem em vários pequenos tratadores, programas que processam os eventos para produzir respostas, e um disparador, que invoca os pequenos tratadores. Uma alternativa consiste em disparar os tratadores por eles próprios, criando um efeito de evento em cascata.
Esse método é bastante flexível e permite um sistema assíncrono. Programas com interface com o usuário geralmente utilizam tal paradigma. Sistemas operacionais também são outro exemplo de programas que utilizam programação orientada a eventos, este em dois níveis. No nível mais baixo encontram-se o tratamento de interrupções como tratadores de eventos de hardware, com a CPU realizando o papel de disparador. No nível mais alto encontram-se os processos sendo disparados novamente pelo sistema operacional.
Um interpretador de comandos pode ser visto como um caso especial de modelo orientado a eventos, no qual o sistema, até então inativo, espera um comando para ser disparado através das instruções do usuário.
Uma arquitetura de referência é um ponto de início. É uma representação, bem genérica e abstrata, que ajuda o time (e o arquiteto) na definição de elementos concretos do sistema. Elas apontam para os principais componentes a serem definidos – orientando indiretamente seus papéis, comportamentos e relacionamentos.
Arquiteturas de referência surgem da observação de determinados tipos de software. Definem e explicitam elementos comuns aplicados por vários profissionais de arquitetura no projeto de vários softwares de um determinado tipo. São representações em alto-nível das similaridades identificadas nessas diversas instâncias.
Considerar uma arquitetura dereferência, ao conceber um novo sistema, poupa ao arquiteto um volume considerável de análise e ponderação na identificação de componentes - seus comportamentos, papéis e relacionamentos.
Arquiteturas de referência não foram criadas para atender conjuntos específicos de requisitos. Isso significa que não podemos pegar uma arquitetura de referência e apontá-la como sendo a arquitetura de um novo sistema sem a avaliação e ajustes indispensáveis. Elas são projetadas para servir como “uma indicação de caminho a seguir”. Uma arquitetura concreta surge da adaptação de uma referência para as necessidades e propósitos de um sistema específico.
Um sistema distribuído é um sistema na qual as informações são distribuídas para vários computadores, em vez de ficarem armazenadas em uma única maquina. Como desenvolver um software utilizando este tipo de arquitetura, as sua vantagens e desvantagens, além de alguns modelos genéricos serão abordados nesta resenha.
Arquitetura de Sistemas Distribuídos
Um sistema distribuído é um sistema na qual as informações em fase de processamento são distribuídas para vários computadores, em vez de ficarem confinadas em uma única maquina. Este tipo de sistema tem vantagens e desvantagens como:
1 Vantagens
a) Compartilhamento de Recursos – Permite o compartilhamento de recursos pelas redes como impressoras, softwares, processamento, discos, e etc.
b) Concorrência – Possibilidade de se ter vários processos ao mesmo tempo em diferentes computadores.
c) Tolerância a defeitos – Pode suportar até algumas determinadas falhas de software ou de hardware.
d) Escalabilidade – Possibilidade de aumentar a capacidade do sistema, seja de recursos físicos (hardware) como virtuais(softwares) para atender novas demandas.
e) Abertura – Utilização de equipamentos e softwares de diferentes fabricantes em conjunto.
2 Desvantagens 
a) Complexidade – Difícil entendimento das propriedades dos sistemas, e com isso, dificuldade para realizar testes no sistema com um todo.
f) Proteção – o sistema é acessado por vários computadores, e com isso todo o trafego está sujeito a interceptação, e consequentemente a alteração dos dados, além de violação de leis de privacidade.
g) - Gerenciamento – Dificuldade no gerenciamento pelos mais variados motivos, como por exemplo, versões de S.O. ou do softwares diferentes, diferenças de hardware entre os usuários, e etc.
h) Imprevisibilidade – A alta demanda de usuários, solicitando informações pode causar respostas fora do padrão ou fora de um tempo aceitável. Estes erros podem ter inúmeras causas, e em muitas vezes fica impossível saber as suas causas num período de tempo curto.
O grande paradigma é projetar um software e o hardware para fornecer os recursos de sistemas distribuídos, desejáveis e, ao mesmo tempo, minimizar os problemas deste tipo de arquitetura.
Pensando em como projetar o software, podemos partir de dois tipos de arquitetura:
Arquitetura cliente-servidor, na qual uns conjuntos de serviços são oferecidos ao cliente. No caso, cliente e o servidor (sistema que oferece os serviços) são tratados de maneira diferente
Arquitetura de objetos distribuídos, que é um conjunto de objetos distribuídos que interagem entre si e não há distinção entre um provedor de serviços de um usuário desses serviços.
Arquiteturas de multiprocessadores
É um dos modelos de sistemas distribuídos mais simples, que consiste em uma serie de processos que podem ou não ser processados por processadores diferentes.
Arquiteturas cliente-servidor
A arquitetura cliente-servidor é um modelo que separa os clientes e os servidores. Neste modelo, as parte são interligadas entre si, geralmente utilizando-se uma rede de computadores.
Cada objeto de um cliente pode enviar requisições de dado para algum dos servidores conectados e esperar pela resposta. Por sua vez, os servidores disponíveis podem aceitar tais requisições, processá-las e retornar o resultado para o cliente. Apesar de o conceito ser aplicado em diversos usos e aplicações, a arquitetura é praticamente a mesma.
Muitas vezes os clientes e servidores se comunicam através de uma rede de computador com hardwares separados, como no caso de um sistema web, mas também o cliente e servidor podem residir no mesmo local. Um cliente não compartilha de seus recursos, mas solicita o conteúdo de um servidor ou função de serviço. Os clientes, portanto, iniciam sessões de comunicação com os servidores que esperam as solicitações de entrada.
A característica de cliente-servidor descreve a relação de programas em um aplicativo. O componente de servidor fornece uma função ou serviço a um ou muitos clientes, que iniciam os pedidos de serviços.
Por exemplo, um navegador da web é um programa cliente em execução no computador de um usuário que pode acessar informações armazenadas em um servidor web na Internet. Outro exemplo seria algum usuário de serviços bancários de algum banco, como o Itaú ou Caixa Econômica Federal, acessando de seu computador via um navegador da Web (aplicativocliente), como o Firefox ou Google Chrome para enviar uma solicitação para um servidor web do banco (servidor).
Cada instância de software do cliente pode enviar requisições de dados a um ou mais servidores ligados. Por sua vez, os servidores podem aceitar esses pedidos, processá-los e retornar as informações solicitadas para o cliente. Embora este conceito possa ser aplicado para uma variedade de razões para diversos tipos de aplicações, a arquitetura permanece fundamentalmente a mesma.
Arquitetura de objetos distribuídos
Na arquitetura de objetos distribuídos os componentes do sistema são objetos que fornecem uma interface para um conjunto de serviços fornecidos. Outros objetos chamam esses serviços sem distinção lógica entre um cliente (receptor de um serviço) e um servidor(provedor de um serviço).
Os objetos podem ser distribuídos entre uma serie de computadores na rede e se comunicam através de um middleware. Esse middleware é chamado de requisitor de objetos. Seu papel é fornecer uma interface transparente continua entre os objetos.
Computação Inter-organizacional distribuída
Por motivos de proteção e interoperabilidade, a computação foi implementada inicialmente em nível organizacional. Uma organização tem uma serie de servidores e distribui a sua carga computacional entre eles.
Devido ao fato de eles estarem todos localizados dentro da mesma organização, pode ser aplicado padrões e processos operacionais locais. Embora, para sistemas baseados na Web, os computadores clientes estejam muitas vezes fora dos limites da organização, sua funcionalidade é limitada a executar um software de interface com o usuário.
Desafio 3 
• Javascript é uma linguagem de programação simples que permite inserir lógica em códigos HTML, adicionando interatividade a elas sem requerer compilação do código.
• Os scripts escritos com a linguagem Javascript, podem ser executados por navegadores (client-side scripts) ou por servidores (server-side scripts).
Arquitetura de Hardware de Suporte ao SD
Hardware
BULL, IBM (Intel), HP (Intel), Dell (Intel) e SUN (Intel)
Plataforma
• Arquitetura orientada a serviços (SOA) – A SOA revoluciona o desenvolvimento de softwares de gestão de negócios, viabilizando a rápida composição de soluções empresariais. Com a SOA sua empresa pode encapsular a lógica dos negócios, expondo-a em forma de serviços corporativos. Isso significa menores componentes de funcionalidades modulares, que poderão ser rapidamente remontados para compor novas soluções corporativas capazes de atender a exigências de negócios em permanente transformação. (em inglês)
• Plataforma SAP NetWeaver - O SAP NetWeaver viabiliza mudanças nos processos de negócios, de forma muito ágil, embora sem a perda do controle. A plataforma incorpora funcionalidades de negócios – em forma de serviços de gestão empresarial de uso imediato, além de componentes de processos – por meio de seu repositório de serviços corporativos. A plataformaSAP NetWeaver fornece também uma plataforma integrada de tecnologias de composição que permite a orquestração dos processos de negócios, a composição de aplicativos e a instalação de soluções inovadoras.
• Tecnologia SAP In-Memory Computing – Inovações revolucionárias de hardware e software que trazem para seus negócios a nova realidade da computação empresarial em tempo real, para gerenciamento e análise de grandes volumes de dados com rapidez e economia, simplificando a TI.
• Ecossistema — Os membros do altamente interativo ecossistema SAP de clientes e parceiros colaboram por meio de uma gama de comunidades e programas, inclusive a SAP Developer Network (SDN), Enterprise Services Community, redes de valor de indústria (IVNs) e soluções de parceiros.
Softwares Utilizados
Um sistema SAP é composto por três camadas:
• Frontend
• Application
• Database
Frontend é camada responsável por "exibir" as telas ao usuário.
Application é onde são processadas as operações efetuadas, transferindo para o Frontend, os dados a serem exibidos. É nessa camada que os programas ABAP são executados.
A camada de Application possui diversos serviços e processos (também chamados de Work Process) disponíveis.
O desenho típico de uma instância SAP é um servidor de Banco de Dados com um ou mais servidores de Application. Isso garante a integridade dos dados, e permite uma distribuição de carga nos servidores de aplicativo entre os usuários.
ABAP (Advanced Business Application Programming) é uma linguagem de programação de alto nível desenvolvida pela empresa de software SAP. É a principal linguagem utilizada no produto mais conhecido desta empresa, o SAP R/3, um software ERP. O ABAP tem uma sintaxe semelhante ao COBOL.
Sistema Operacional
UNIX, Solaris e Windows NT, Server 2003 ou superior
Arquitetura da Base de Dados
Banco de Dados
ADABAS D - DN2 for AIX - INFORMIX –ORACLE
ADABAS D - MS SQL SERVER – ORACLE
Message: Serviço interno responsável pela comunicação entre as instâncias.
Dispatcher: Serviço interno responsável pelo "despacho" das requisições para cada processo ou serviço.
Gateway: Garante a comunicação externa com outros sistemas.
Enqueue: Processo responsável pelo gerenciamento da tabela de objetos de bloqueio.
Dialog: Processo responsável pela execução dos processos visiveis pelo usuário.
Update: Processo responsável pela atualização dos dados no banco de dados.
Spool: Processo que gerencia a fila de impressão.
Database é a camada onde os dados são armazenados, quando a camada Application necessita de algum dado, o mesmo é requisitado a camada de Database. 
Características - Suporta os principais conceitos de orientação a objetos. Favorece a extensibilidade e reusabilidade. Contém bibliotecas especiais que possibilitam o trabalho com protocolos TCP/IP como HTTP e FTP. Não Contém redundâncias e é fácil de entender, implementar e usar. 
Vantagem - Java tem uma API padrão que roda em vários tipos de plataformas, você consegue fazer desde os sistemas mais básicos até os mais complexos e distribuídos sem ter que recorrer a milhares de ferramentas diferentes.Conjunto de bibliotecas disponíveis, que contém centenas de funções prontas para serem usadas, bastando importar as classes que contém tais métodos. 
Desvantagem - Por rodar em uma máquina virtual, aplicativos em Java tendem a perder um pouco em rapidez do que programas escritos em outras linguagens que geram arquivos através da compilação 
Ambiente De Desenvolvimento
A linguagem Java vem sofrendo aprimoramentos desde o seu lançamento. O aumento no número de aplicações e, consequentemente, o aumento no número de bibliotecas padrão da linguagem, levou à criação de três divisões na plataforma a partir da versão 2 da linguagem: J2SE, J2EE e J2ME. Essas divisões são chamadas por alguns de ambientes de desenvolvimento. No entanto, há quem as denomine profile, plataforma, versão, entre outros. É importante ressaltar que, a partir de 2006, passou-se a utilizar uma nova nomenclatura para essas plataformas. O número 2 foi retirado das siglas que as representam. Assim, estas passaram a ser JSE, JEE e JME.
Ambiente JME
O ambiente JME (Java Micro Edition) que é voltado para a programação de dispositivos móveis, foi se expandindo com a evolução dos aparelhos celulares. E por ser uma linguagem open source a maioria dos aparelhos possui a JMV (Java Virtual Machine), para a execução dos aplicativos JAVA. Na figura abaixo mostra a arquitetura Java Micro Edition, mostrando como é feita a comunicação e execução dos aplicativos JME, descrevendo os componentes que cada pacote [LEMAY 1997].
Como a linguagemJava já era conhecida e a adaptação ao JME não é complicada, logo surgiram diversos tipos de aplicativos para tais dispositivos, como jogos e agendas eletrônicas. As empresas saíram ganhando com isso porque, desde que seus dispositivos tenham uma JVM (Java Virtual Machine - Máquina Virtual Java), é possível, com poucas modificações, implementar os aplicativos em qualquer aparelho, sendo o único limite a capacidade do hardware.
A plataforma JME contém configurações e bibliotecas trabalhadas especialmente para a atuação em dispositivos portáteis. Assim, o desenvolvedor tem maior facilidade para lidar com as limitações de processamento e memória, por exemplo. Um exemplo disso é a configuração chamada CLDC (Connected Limited Device Configuration), destinada os dispositivos com recursos de hardware bastante limitados, como processadores de 16 bits e memórias com 512 KB de capacidade. Essa configuração contém uma JVM e um conjunto básico de bibliotecas que permite o funcionamento da aplicação Java em dispositivos com tais características.
Desafio 4
O modelo adequado de arquitetura que poderemos utilizar para a Empresa China Telecom seria a Engenharia de Requisitos, pois os problemas que os engenheiros de software têm para solucionar são, muitas vezes, imensamente complexos, difícil estabelecer com exatidão o que o sistema deve fazer. O processo de descobrir, analisar, documentar e verificar as funções e restrições de um sistema é chamado de engenharia de requisitos. Por sua vez, estas descrições são os requisitos e podem ser classificados como:
Funcionais - Descreve explicitamente como o sistema deve se comportar em determinadas situações. 
Não Funcionais - São restrições sobre os serviços fornecidos pelo sistema, por exemplo, restrições sobre desempenho, arquitetura, desenvolvimento. 
Os de Domínio - São requisitos funcionais ou não funcionais derivados do domínio de aplicações do sistema (e não a partir da necessidade do usuário). 
No processo de engenharia de requisitos fazemos um estágio de extrema importância, o de levantamento e análise de requisitos. Este consiste na interação com os stakeholders para descobrir as informações sobre o domínio das aplicações e serviços que o sistema da Empresa China Telecon deve prove, onde o processo vai abrange as seguintes atividades: stakeholder é utilizado para se referir a qualquer pessoa que terá alguma influência direta ou indireta sobre os requisitos do sistema.
Na compreensão do domínio - Os analistas devem desenvolver sua compreensão de domínio da aplicaões, pois isso irá facilitar muito a interação com os stakeholders, pois eles expressam naturalmente os requisitos em seus próprios termos e com o conhecimento implícito de sua área de atuação. 
Já na coleta de Requisitos - Esse processo irá interagir com os stakeholders do sistema para descobrir seus requisitos. A compreensão do domínio se desenvolve mais durante esta atividade. 
Na classificação - Essa atividade considera o conjunto não estruturado dos requisitos e os organiza em grupos coerentes. 
A resolução de conflitos - Quando múltiplos stakeholders estão envolvidos, os requisitos apresentarão conflitos. Essa atividade se ocupa de encontrar e solucionar conflitos 
Com a definição das prioridades - Este estágio envolve a interação com os stakeholderspara descobrir os requisitos mais importantes 
Enfim com a verificação de requisitos - Os requisitos são verificados a fim de se descobrir se eles são completos e consistentes e se estão em concordância com o que os stakeholders desejam do sistema. 
É importante notar que fatores políticos podem influenciar os requisitos do sistema, e os requisitos e suas prioridades podem mudar ao longo de todo desenvolvimento, pois o ambiente econômico e de negócios no qual a análise de requisitos ocorre é dinâmico. 
Podemos utilizar na Empresa China Telecom algumas técnicas muito para o levantamento e análise de requisitos:
Cenários 
Muitas vezes é mais fácil relacionar exemplos da vida real do que descrições abstratas. Para tanto, montamos um cenário composto por interações entre entidades (podem ser objetos ou usuários) e a partir destas informações traçarem os requisitos reais do sistema. Este processo pode ocorrer mesmo informalmente nas interações com os stakeholders, mas existem formas mais estruturadas, como os use-cases.
Basicamente podemos observar que um use-case identifica os agentes envolvidos em uma interação e especifica o tipo de interações. O use-case se tornou uma característica fundamental das notações em UML (Unified Modeling Language) para descrever modelos de sistemas orientados a objetos, e por isso estes processos estão sendo cada vez mais utilizado. Além disso, os diagramas de sequência em UML podem ser utilizados para acrescentar informações a um use-case.
CONCLUSÃO
O profissionalismo e estudo empregado a desenvolver e programar é complexo e possui varias formas de se interagir, a sociedade e a comunicação são fatos importantes na interpretação para solucionar o problema que é empregado ao programador.
E cada vez mais as empresas notam como um sistema de informação distribuído é indispensável devido ao grande fluxo de informações que são geradas, armazenadas e reutilizadas diariamente.
A China Telecom mostrou como é possível integrar setores através da implantação de um sistema distribuído completo como o mySAP e obter ótimos resultados administrativos, operacionais, de pessoal e financeiros, cumprindo assim o papel do auxílio da tecnologia ERP no âmbito empresarial.
REFERÊNCIAS
ALENCAR, A. J., SCHMITZ, E. A., Análise de Risco em Gerência de Projetos. Rio de Janeiro, Editora Brasport, 2006. 
BERNSTEIN, P., O Desfio aos Deuses: A Fascinante História do Risco. Rio de Janeiro, Campus, 1997. 
BOEHM, B., Software risk management: principles and practices. Piscataway: IEEE Software,1991. CHAOS REPORT, Disponível em: 
http://itprojectguide.blogspot.com/2009/04/standish-2009-chaos-report.html Acessado em: 15 de Abril de 2015. 
DINSMORE, P. C., Como se Tornar um Profissional em Gerenciamento de Projetos. 2ª ed. Rio de Janeiro, Editora Qualytmark, 2005. 
GURGEL, C. G. S., Curso preparatório para certificação PMP. PMI-CE Fortaleza, 2007. GUSMÃO, C. M. G., MOURA, P. H., ISO, CMMI, and PMBOK Risk Management: a Comparative Analysis. The International Journal of Applied Management and Technology, Volume 1, Number 1. 2003. 
LEOPOLDINO, C. B., Avaliação de Riscos em Desenvolvimento de Software. Dissertação de Mestrado - Mestrado em Ciências da Computação, Universidade Federal do Rio Grande do Sul, Porto Alegre, 2004. 
MACHADO, C. (2002) A-Risk: Um método para identificar e quantificar risco de prazo em projetos de desenvolvimento de software. Curitiba, 2002. 86 
VARGAS, R. Gerenciamento de riscos e de projetos. Disponível em: http://www.ricardo-vargas.com/pt/podcasts/riskmanagement/ . Acessado em: 10 de Abril de 2015.
Sistema de Ensino Presencial Conectado
ANALISE E DESENVOLVIMENTO DE SISTEMA
bryan seconello guedes
PORTIFOLIO INDIVIDUAL
Campo Novo do Parecis
2015
bryan seconello guedes
Portfólio Individual
Orientador: Prof: Márcio Roberto Chiaveli; Luis Claudio Perini e Marco Ikuro Hisatomi; Veronice de Freitas
Campo Novo do Parecis
2015