Google+

Tradutor

Artigos

Artigos Científicos Interessantes



Artigo - Power Over Ethernet (POE)
Power Over Ethernet (POE)
Carlos Aurélio Pereira
Faculdades Associadas de Santa Catarina (FASC)
Rua. Henrique Lage, Centro – 88.806-000 – Criciúma – SC – Brasil
billsombrio@gmail.com


Abstract. In many situations, access points and other network devices must be installed in places of difficult access. In such cases, besides the cable network, you need to install electricity, which increases costs. The Power over Ethernet, or PoE, is a standard that allows transmitting power using its own cable network, along with data, which solves the problem ...




Resumo. Em muitas situações, pontos de acesso e outros dispositivos de rede precisam ser instalados em locais de difícil acesso. Nesses casos, além do cabo de rede, é necessário fazer a instalação elétrica, o que aumenta os custos. O Power over Ethernet, ou PoE, é um padrão que permite transmitir energia elétrica usando o próprio cabo de rede, juntamente com os dados, o que soluciona o problema..




Introdução
Tudo começou com projetos artesanais, que utilizavam os dois pares de fios não usados para transmitir dados (em redes de 100BaseT, de 100 megabits) nos cabos de par trançado cat-5 para enviar corrente elétrica para dispositivos do outro lado do cabo, eliminando a necessidade de usar uma fonte de alimentação separada. Com o passar do tempo, a idéia acabou pegando e deu origem ao padrão IEEE 802.3af, ratificado em 2005, que já é suportado por diversos produtos.


No padrão, dois dos quatro pares de fios do cabo de par trançado são utilizados para transmitir uma corrente com tensão de 48 volts e até 400 mA o que, depois de descontadas todas as perdas, resulta em uma capacidade de fornecimento de até 12.95 watts. A energia é suficiente para alimentar a grande maioria dos pontos de acesso, telefones VoIP e outros dispositivos menores ou até mesmo um notebook de baixo consumo.

Um sistema especial de modulação permite que os dois pares que transmitem energia sejam usados também para transmitir dados, o que permite o uso em conjunto com dispositivos Gigabit Ethernet. A tecnologia não é muito diferente da utilizada desde o início do século passado no sistema telefônico, que também transmite uma corrente com tensão de 48 volts (usada para alimentar o aparelho) juntamente com o sinal de voz.

Visão Geral
Existem duas opções para utilizar o PoE. A primeira é utilizar um conjunto de injector (injetor) e splitter (divisor) posicionados entre o switch e o dispositivo que vai receber energia. O injetor é ligado na tomada e "injeta" energia no cabo, enquanto o splitter separa a corrente elétrica do sinal de rede, oferecendo dois conectores ao dispositivo: um conector de rede e um conector de energia, ligado no lugar da fonte:



Usar o injetor e o splitter é a solução mais simples, já que você não precisa mexer no resto da estrutura da rede, mas não é necessariamente a mais barata, já que você precisa comprar dois dispositivos adicionais para cada aparelho que precisar receber energia.

A segunda solução, mais viável para situações em que você queira usar o PoE para vários dispositivos é usar diretamente um PoE switch (um switch Ethernet capaz de enviar energia em todas as portas) e apenas pontos de acesso e outros dispositivos compatíveis, eliminando a necessidade de usar injectors e splitters:



O switch é capaz de detectar se o dispositivo ligado na outra ponta do cabo suporta ou não o PoE, o que é feito medindo a resistência. Só depois de detectar a presença de um dispositivos compatível é que ele inicia a transmissão de corrente. Isso permite que você conecte também dispositivos "normais" ao switch, sem risco de queimá-los.

É possível ainda usar soluções híbridas, combinando um ponto de acesso (ou outro dispositivo) com suporte nativo ao PoE com um switch comum. Nesse caso, você precisa apenas do injetor, já que o dispositivo recebe a corrente diretamente, através do cabo de rede.


3. IEEE 802.3af
Norma IEEE validada em Junho de 2003. Define a alimentação eléctrica de equipamentos através de uma cablagem Ethernet em cobre, simultaneamente à transmissão de dados. Este tipo de tecnologia tem diferentes designações: Ethernet activa, Power-over-Ethernet (PoE), Power-over-Lan (PoL), corrente em linha…

PSE
Equipamento que injecta corrente no cabo Ethernet

PD
Equipamento que recebe a sua alimentação eléctrica através do cabo EthernetDesde Junho de 2003 que a norma IEEE 802.3af especifica a alimentação de corrente eléctrica através do cabo Ethernet existente.

Segundo a norma 802.3af, o equipamento que injecta a electricidade no cabo – designado por Power Sourcing Equipment (PSE) – tem de fornecer uma corrente directa de 48V.

Powered Device (PD) – não deverão consumir mais do que 12,95W, nem estarem a mais de 100 metros de distância (como acontece para qualquer ligação Ethernet sobre cobre) do comutador que os liga.
4. Meu POE caseiro
Tendo em vista que os pinos 4 e 5 e os 7 e 8 não são utilizados para dados no padrão 100 BaseT. E que alguns fabricantes usam estes para carregar a voltagem DC isto é variando de fabricante para fabricante.
O primeiro lado criei o Injetor com uma emenda RJ45, separei os pinos 1,2,3,6 para dados e 4,5 para positivo e 7,8 para negativo. Liguei um led via resistor de 1k2 na alimentação e coloquei um plug P4 fêmea.
No outro lado o Conversor utilizei a mesma coisa, apenas substituindo o plug P4 por um macho. Para ser ligado ao quipamento que receberá a energia.


5. Conclusões
Sem dúvida a tecnologia IEEE 802.3af é algo que facilita muito, pois economiza em cabos e estrutura. Com tudo torna-se mais pratico e visualmente limpo o ambiente, sem a poluição visual dos cabos.


6. Referências:

[1] LEHR, Amir. (2004) "PoE: O que isso significa para VoIP". Disponível em:
. Acesso em: Maio 2009.

[2] POE como fazer?. Disponível em: . Acesso em: Maio 2009.

[3] Mundo Wi-Fi. Disponível em: . Acesso em: Maio 2009.

[4] Julio Battiste. Disponível em: . Acesso em: Maio 2009.

PS. Escrito em junho de 2009.
Postado por Carlos A Pereira às 22:18 1 comentários


================================================================================================



Artigo - Sistema de arquivos em sistemas Linux
Sistema de arquivos em sistemas Linux
Carlos Aurélio Pereira
Universidade do Extremo Sul Catarinense (UNESC)
Av. Universitária, 1105 – Bairro Universitário – 88.806-000 – Criciúma – SC – Brasil
billsombrio@gmail.com


Abstract. The system of files of an operating system is what defines how they will be recorded and recovered the information in disk, as well as your integrity and safety. The Linux stands out for possessing compatibility and flexibility with big I number of systems of files. Systems these as Ext3, ReiserFs, XFS and JFS. That stand out for the great efficiency in the treatment of the inconsistencies with efficient methods like Journaling.




Resumo. O sistema de arquivos de um sistema operacional é o que define como serão gravadas e recuperadas as informações em disco, bem como a sua integridade e segurança. O Linux se destaca por possuir compatibilidade e flexibilidade com grante numero de sistemas de arquivos. Sistemas estes como Ext3, ReiserFs, XFS e JFS. Que se destacam pela grande eficiência no tratamento das inconsistências atravez de metodos eficiêntes como o Journaling.




Introdução
O Linux possui excelente desempenho no gerenciamento de dados, tanto no que diz respeito ao armazenamento, quanto nas alocações e atualizações de informações. Dentre vários, um dos grandes responsáveis por tanta eficiência é o sistema de arquivo (ou filesystem) ext3 (sigla para third extended file system), que passou a ser integrado definitivamente ao Linux (kernel) a partir da versão 2.4.

Visão Geral
Um sistema de arquivos é uma estrutura que indica como os dados devem ser gravados em dispositivos de gravação. É de acordo com os recursos oferecidos por essa estrutura que é possível determinar o espaço disponível e ocupado em disco, e gerenciar como partes de um arquivo podem ficar "distribuídas" nas áreas de armazenamento. É também o sistema de arquivos que determina como os dados podem ser acessados, copiados, movidos, renomeados, protegidos e eliminados. Portanto, sem um sistema de arquivos, é impossível utilizar um disco rígido (e outros dispositivos) para armazenamento de informações.

Método

Os sistemas de arquivos são criados em partições do disco, de forma que seja possível armazenar programas e dados em formato de arquivos e diretórios (pastas). O Linux, assim como praticamente todos os sistemas operacionais baseados em Unix, usa um sistema de arquivos que possue uma hierarquia, composta de arquivos e diretórios, que podem conter outros diretórios ou arquivos.
Os arquivos/diretórios (sistemas baseados em Unix tratam os diretórios como arquivos específicos) em um sistema de arquivos para Linux são disponibilizados (ou montados) para manipulação através do comando "mount", geralmente acionado no processo de startup (inicialização), que ocorre quando o computador é ligado e começa a carregar o sistema operacional. O Linux consegue trabalhar com vários sistemas de arquivos em um mesmo disco (situação comum à usuários que possuem Windows e Linux em suas máquinas, por exemplo) e, para "enxergá-los", armazena a lista de sistemas de arquivos disponíveis no arquivo /etc/fstab (repare que /etc/ indica um caminho de diretório). No entanto, há uma lista de sistemas de arquivos que estão efetivamente em uso, disponível no arquivo /etc/mtab, também conhecido como "tabela mount". Esta lista é atualizada no processo de startup, para indicar ao sistema operacional quais sistemas de arquivos ele poderá acessar.
Para cada sistema de arquivos montado no startup, um bit no cabeçalho do sistema de arquivos é zerado para indica que o sistema de arquivos está em uso a partir daquele momento e que as estruturas de dados usadas para a alocação e organização de arquivos/diretórios podem sofrer mudanças (atualizações).
Quando o usuário decide desligar o computador e usa comandos para encerrar o Linux, os sistemas de arquivos são desmontados, fazendo com que o bit citado acima seja modificado para indicar que o sistema de arquivos está consistente, ou seja, não pode mais sofrer mudanças.

3.1 Inconsistências no sistema de arquivos

O sistema de arquivos para Linux sofre constante tratamento e reescrita de código para eliminar o corrompimento causado por aplicações ou pelo próprio kernel. No entanto, eliminar o corrompimento de dados em arquivos causados, por exemplo, pela queda de energia ou pelo desligamento incorreto por parte do usuário, é uma tarefa praticamente impossível. Quando o sistema é desligado incorretamente o bit do cabeçalho do sistema de arquivos não é ajustado. A solução foi fazer com que, no próximo processo de carregamento do Linux, seja verificado se o cabeçalho está com o bit de cabeçalho setado para indicar que o sistema de arquivos está consistente e não manipulável. Caso não esteja, a ferramenta "fsck" verifica o sistema na busca de erros.
O fsck consegue resultados satisfatórios, mas a correção de erros pode levar muito tempo, tempo este inaceitável em aplicações críticas. Além disso, se o desligamento incorreto do computador ocorreu quando dados estavam sendo gravados no disco, o fsck não conseguirá completar esses processos, ocasionando a perda das informações que estavam sendo gravadas.




3.2 Journaling

A tecnologia "Journaling", que possuem a capacidade de acompanhar as mudanças que serão feitas no sistema de arquivos (por exemplo, gravações/atualizações de dados) antes que realmente sejam feitas. Essas informações que o Journaling captura é então armazenado em uma parte separada do sistema de arquivos, denominada "Journal" (mas também conhecida por "registros de log"). Quando as informações são armazenadas no Journal, o sistema de arquivos aplica as mudanças registradas nele e então, remove as informações do Journal.

O Journaling é uma solução eficiente para os problemas de erro. Os registros de log são escritos antes que as mudanças efetivamente ocorram no sistema de arquivos e esses registros somente são eliminados quando as mudanças são feitas. Assim, se o computador é indevidamente desligado, o processo de montagem no próximo startup verificará se há mudanças gravadas no Journal "marcadas" como não feitas. Se houver, tais mudanças são então aplicadas ao sistema de arquivos. Isso faz com que os riscos de perda de dados sejam reduzidos drasticamente.


Características dos principais sistemas de arquivos baseados em Journaling

Ext3 – Nada mais é do que a união entre o Ext2 com o Journaling. O suporte a ele já se encontra disponível em várias distribuições Linux, incluindo Mandriva e RedHat. O suporte também pode ser adicionado através de uma recompilação do kernel v2.4.

ReiserFs - Projetado por Hans Reiser, tem a grande vantagem de ser o primeiro sistema de arquivos baseado em journaling a ser incluído como parte integrante do kernel do Linux. Permite arquivos com até 2 Gb de tamanho. Possui otimizações para trabalhar com arquivos pequenos, reduzindo a fragmentação.

XFS - Criado em 1994 pela SGI para substituir outro sistema de arquivos (EFS), tornou-se disponível para Linux em Jul/2001 pela licença GPL. Projetado especialmente para trabalhar com arquivos grandes (de até 9 mil “petabytes”) e diretórios com vários arquivos, pode trabalhar com tamanho de bloco variando de 512 bytes até 64 Kb.

JFS - Criado pela IBM para uso em servidores corporativos “high-throughput server environments, key to running intranet and other high-performance e-business file servers”. Permite o emprego de blocos com tamanho de 512,1024, 2048 e 4096 bytes. Para um tamanho de bloco de 512 bytes, o tamanho máximo de um arquivo é de 512 Tb, para um tamanho de bloco de 4Kb, o tamanho máximo de um arquivo é de 4 petabytes. Incorporado na v2.5.6 do kernel para o sistema operacional Linux.

Ext3 Características do sistema de arquivos
No ext3, o código de Journaling usa uma camada chamada "Journaling Block Device" (JBD). A JBD foi criada com o propósito de implementar Journal em qualquer tipo de dispositivo com base em blocos de dados. Por exemplo, o código ext3 informa e "pede autorização" à JDB para efetuar as mudanças, antes de modificar/adicionar qualquer dado no disco. Sendo assim, é o JDB que verdadeiramente "gerencia" o Journal. O fato mais interessante disso é que, a JDB funciona como uma entidade independente, permitindo que não só o ext3 a use, mas também outros sistemas de arquivos.

A JDB utiliza um método diferente de outros Journalings para recuperação de informações. Ao invés de armazenar as informações em bytes que depois devem ser implementados, a JDB grava os próprios blocos modificados do sistema de arquivos. Assim, o ext3 também armazena "réplicas" completas dos blocos modificados em memória para rastrear as operações que ficaram pendentes. A desvantagem desta forma de trabalho é que o Journal acaba sendo maior. No entanto, o ext3 não precisa lidar com a complexidade dos Journalings que trabalham gravando bytes.

O ext3 suporta três diferentes modos de trabalho do Journaling. São eles:

Journal: grava todas as mudanças em sistema de arquivos. É o mais lento dos três modos, mas é o que possui maior capacidade de evitar perda de dados;

Ordered: grava somente mudanças em arquivos metadata (arquivos que guardam informações sobre outros arquivos), mas guarda as atualizações no arquivo de dados antes de fazer as mudanças associadas ao sistema de arquivos. Este Journaling é o padrão nos sistemas de arquivos ext3;

Writeback: também só grava mudanças para o sistema de arquivo em metadata, mas utiliza o processo de escrita do sistema de arquivos em uso para gravação. É o mais rápido Journaling ext3, mas o menos confiável.

O modo Ordered é o padrão no ext3, mas é possível especificar qual o modo que você deseja usar, através da atualização do arquivo fstab. Por exemplo, pode ser que a linha /dev/hda1/opt tenha sua opção data com o valor ordered. Você pode mudar este valor para writeback ou journal.

.

8. Conclusões

Com base nos recursos e na grande disponibilidade que o linux tem em usar diferentes tipos de sistemas de arquivos é que se faz cada vez mais presente o uso do linux tanto no meio corporativo como no domestico.


Referências:

[1] CHRISTIAN, Kaare, Sistema Operacional UNIX; Tradução de REINPRECHT, Ricardo. Editora Campos, Rio de Janeiro, 1987.

[2] Exploring the ext3 Filesystem. Disponível em: . Acesso em: Junho 2007.

[3] FEDORA, Porjeto Fedora. Home Page. Disponível em: . Acesso em: Junho 2007.

[4] OLIVEIRA, de Rômulo Silva, CARISSIMI, Alexandre da Silva e TOSCANI, Simão Sirineo, Sistemas Operacionais. Instituto de Informática da UFRGS: Editora Sagra Luzzatto, Porto Alegre, 2004.

[5] SIBERSCHATZ, Abraham, GALIN, Peter e GAGNE, Greg, Sistemas Operacionais: Inclui Java; Tradução de RIECHE, Adriana. Editora Campos, Rio de Janeiro, 2000.

[6] SIBERSCHATZ, Abraham, GALIN, Peter e GAGNE, Greg, Sistemas Operacionais: Com Java; Tradução de VIEIRA, Daniel. Editora Campos, Rio de Janeiro: Eusevier, 2004.

[7] TANEBAUM, Andrew S., Sistemas Operacionais Modernos; Tradução de FILHO, Nery Machado. Editora Prentice Hall, Rio de Janeiro, 1995.

PS. Escrito em julho de 2007.
Postado por Carlos A Pereira às 22:16 0 comentários



================================================================================================



Artigo - Processo Unificado da Rational/IBM (RUP)
Processo Unificado da Rational/IBM (RUP)
Carlos Aurélio Pereira
Universidade do Extremo Sul Catarinense (UNESC)
Av. Universitária, 1105 – Bairro Universitário – 88.806-000 – Criciúma – SC – Brasil
billsombrio@gmail.com


Abstract. RUP, abbreviation of Rational Unified Process, is a process proprietor of software Engineering created by Rational Software Corporation, acquired for IBM becoming a prominence in the software area supplying techniques be her followed for the members of the team of software development with the objective of increasing your productivity. RUP uses the approach of the orientation to objects in your conception and it is projected and documented using the notation UML (Unified Modeling Language) to illustrate the processes in action.

Resumo. O RUP, abreviação de Rational Unified Process (ou Processo Unificado da Rational), é um processo proprietário de Engenharia de software criado pela Rational Software Corporation, adquirida pela IBM tornando-se um destaque na área de software fornecendo técnicas a serem seguidas pelos membros da equipe de desenvolvimento de software com o objetivo de aumentar a sua produtividade. RUP usa a abordagem da orientação a objetos em sua concepção e é projetado e documentado utilizando a notação UML (Unified Modeling Language) para ilustrar os processos em ação.

Introdução
Consta como início do RUP à metodologia da empresa Ericsson, que usava um método baseado em componentes, que se agrupavam desde uma visão de baixo nível até atingir-se subsistemas de alto nível. A especificação de blocos ou componentes se uniam e cooperavam entre si. Isso se dava pelos casos de negócios, que deveriam ser previamente identificados. Gerando uma serie de diagramas que mostravam como os diferentes blocos se comunicavam dinamicamente para satisfazer os casos de negócio. Entre os anos de 1987 e 1995, Jacobson lança e evolui um processo de desenvolvimento de software chamado Objectory, na sua empresa ‘Objectory AB’. Nesse processo verifica-se um aprofundamento e um amadurecimento do conceito de casos de uso. No final de 1995 a Rational Software Corparation compra a Objectory AB, com o propósito de unificar os princípios básicos dos diferentes processos de desenvolvimento. A partir de 1997 se desenvolve o Rational Objectory process (ROP), fruto da união das duas empresas, adota-se o UML Linguagem de modelagem Unificado, como linguagem de modelagem.[3] A partir daí surge o RUP e atualmente a empresa pertencente a IBM.

Visão Geral do RUP
O RUP utiliza orientação a objetos e é projetado e documentado utilizando UML, para ilustrar os processos em ação. É um processo de desenvolvimento de softwares aplicado em grandes projetos que detenham grandes equipes de desenvolvedores. Porem como é bastante custumizável, pode ser aplicado em projetos de menor escala. Interativo e incremental o sistema é construído através de vários mini-projetos que se repetem (Interações), guiado por casos de uso, com isso reduzindo riscos e aumenta a confiabilidade em relação ao cumprimento de metas e prazos.

Método
O RUP baseia-se em uma série de princípios considerados fundamentais para o desenvolvimento de um software:

Desenvolvimento Interativo
Gerencia de Requisitos
Arquitetura Baseada em Componentes
Modelagem Visual
Verificação Continua da Qualidade
Controle de Mudanças

3.1 Desenvolvimento interativo
Facilita os ajustes táticos dos requisitos e de novas características do sistema, com isso provoca-se a identificação antecipada de riscos no projeto. Cada interação passa por todas as atividades (Disciplinas) (Figura 1 e 2), seja ela na fase de elaboração, construção ou transição. Com isso se tem uma instalação do produto e versão a cada interação, diminuindo assim os riscos. Podendo assim ter um melhor aprendizado e melhorias continuas no processo, possibilitando o reuso e tendo como produto sistemas mais robustos.

Figura 1

Figura 2


3.2 Gerencia de Requisitos
Forma de documentar a elaboração de um sistema, elicitar, organizar, gerenciar requisitos, elencar, controlar suas mudanças ao longo do projeto. Porem pode-se ter algumas dificuldades como requisitos não óbvios, alguns nem sempre são bem escritos, e o numero de requisitos pode se tornar incontrolável. Por esta razão devemos gerenciar de forma eficaz, para atingirmos nossos objetivos (Figura 3) que é o domínio do problema.

Figura 3


3.3 Arquitetura Baseada em Componentes
Possibilita com isso a reutilização e adaptação de componentes, componentes estes que são subsistemas (Figura4), interações anteriores, módulos pacotes, algo já existente no sistema, tendo-se uma reutilização ou uma customização.

Figura 4

3.4 Modelagem Visual
Utilizando ferramentas de modelagem visual como o XML, tem-se uma melhor facilidade na administração de modelos (Figura 6), modelos estes criados para ajudar o desenvolvimento a construir, documentar a estrutura e o comportamento do sistema. Facilita a comunicação entre a equipe do projeto e os usuários (Figura 5). Com isso os diferentes membros do projeto podem comunicar suas decisões sem ambigüidades.

Figura 5
Figura 6

3.5 Verificação Continua da Qualidade
Deve-se avaliar continuamente a qualidade, com relação à funcionalidade, confiabilidade e validação. Isso envolve a avaliação de versões intermediarias do produto e dos artefatos completados ao final de cada interação ao longo do projeto. Qualidade não é responsabilidade ou função de um só, e sim de todos os envolvidos no projeto. Em todas as fases, ela só será alcançada se for medida e documentada.
Os custos se tornam mais autos após a implantação (Figura7), por esta razão a verificação continua da qualidade é essencial.
Figura 7

3.6 Controle de Mudanças
Em todos os projetos de desenvolvimento de softwares existem varias mudanças em seu decorrer, estas mudanças por menores que sejam podem afetar a aplicação. Com isso é essencial o controle de mudanças, ou versões. O RUP trata isso com um fluxo de trabalho bem definido, o que pode ser repetido para todas as fases do projeto. Isso é importante para se manter uma rastreabilidade de defeitos, falhas de atendimento e comprometimento de projeto bem como associar esta atividade com artefatos específicos. Estas estatísticas de mudanças servem como métricas para o desenvolvimento de softwares futuros. A quantidade de mudanças é controlável e calculável.

Considerações sobre o Método
O processo de desenvolvimento de software utilizando RUP, se da através de uma série de ciclos, que constituem uma versão final do produto. Cada ciclo é constituído de quatro fases (Figura 8):

Figura 8

4.1 Concepção
Nesta fase se estabelece o escopo e a viabilidade econômica do projeto.

4.2 Elaboração
Nesta fase busca-se identificar e eliminar os principais riscos, estabelecendo-se uma arquitetura confiável, a partir do qual o sistema poderá evoluir.

4.3 Construção
È a implementação, desenvolvimento do sistema, que ocorre de forma interativa, em cada uma de suas fases, ate chegar ao produto final.

4.4 Transição
Nesta fase o produto pronto em sua versão (Beta) é disponibilizado ao usuário, com isso são colhidas contribuições para evolução do produto e um novo ciclo se inicia envolvendo todas as fases novamente.

È em cada uma destas fases que se desenvolvem as interações, abrangendo uma série de Fluxo de trabalho (Figura 9) (Atividades ou Disciplinas).

Figura 9

Em cada uma destas fazes (concepção, elaboração, construção e transição), podem ser necessárias varias interações, cada interação é um ciclo dentro da fase que pode compreender até nove atividades (Workflow)[1], conforme figura 3.
Tais atividades podem ser divididas em dois blocos, nos quais os primeiros seis da Engenharia de Software e os três últimos do suporte.

5. Modelagem do Negócio (Business Modeling)
Trata-se da socialização ou entendimento partilhado de toda a equipe, quanto a estrutura, dinâmica e o modelo de gestão da organização do cliente. Com isso tanto o usuário quanto a equipe de desenvolvimento terá uma mesma visão (Figura 10) do cliente para o qual é planejado um novo software.
Figura 10


5.1 Requerimentos (Requirements)
È a busca, compreensão e documentação dos requisitos do sistema, bem como a gestão do escopo e mudanças. Neste caso é importante definir uma interface de usuário para o sistema, (Figura 11) focando nas necessidades e metas do usuário.
Figura 11

5.2 Análise e Projeto (Analysis and Design)
Conversão ou transformação dos requisitos levantados em especificações técnicas que descrevam como implementar o software.

5.3 Implementação (Implementation)
Criação do software seguindo as especificações técnicas existentes, passadas pela análise do projeto. Espera-se que esta implementação seja desenvolvida segundo os conceitos de orientação a objetos e sejam testadas e concluídas as interações com outros sistemas.

5.4 Testes (Test)
Devem ser realizados os testes de conjunto (sistema criado) e de integração com outros sistemas, bem como testes de validação, checando se os resultados são compatíveis com os requisitos especificados.
5.5 Desenvolvimento (Deployment)
È o planejamento de beta testes, atividades de empacotamento de software, distribuição, instalação e treinamento de usuários (Figura 12).

Figura 12


5.5 Gestão de Configuração (Configuration and change Management)
Gerenciamento de todos os artefatos criados durante o processo de desenvolvimento do software.

5.6 Gestão de Projeto (Project Management)
Atividades de planejamento, acompanhamento do desenvolvimento do projeto e gerenciamento dos riscos.

5.7 Ambiente (Environment)
Organização do ambiente de trabalho para a equipe do projeto, e o acompanhamento da configuração do RUP para o projeto.

6. Alguns conceitos do RUP
No ambiente de desenvolvimento de software que utiliza RUP, usa-se alguns conceitos como:

6.1 Artefato
Refere-se a informação tangível que é utilizada, criada ou alterada pelas pessoas competentes ao projeto, em suas atividades. Representa uma área de responsabilidade, a qual deve ser considerada no controle da configuração do modelo.

6.2 Atividade
Trata-se de uma unidade tangível de trabalho bem delimitado, que é realizado por uma pessoa dentro de uma rotina, com responsabilidades bem definidas, produzindo um resultado que possa ser avaliado a partir de entradas conhecidas.

6.3 Modelo
È uma completa descrição de um sistema a partir de uma abstração.

7. Conteúdo do RUP
O que é o RUP afinal? Sabemos neste ponto que é uma metodologia completa e vimos sua estrutura básica. Porém o que ele oferece?
O RUP, além de uma metodologia, é um produto comercializado pela Rational, que é uma grande documentação baseada em hipertexto (HTML). Do conteúdo deste material, destacamos os seguintes assuntos:
Workflows: Cada workflow é descrito em detalhe, apresentando passo a passo as tarefas, subprodutos a serem gerados e papéis de profissionais envolvidos. Cada tarefa, subproduto e papel é descrito em detalhe. Este modelo pode ser seguido à risca ou adaptado conforme sua necessidade específica.
Tarefas: Cada tarefa é descrita em detalhe, incluindo que papel é responsável por ela, a qual workflow ela pertence e quais são os subprodutos de entrada e saída.
Modelo de equipe: Os diversos papéis necessários no projeto são descritos em detalhe. Assim como no MSF, cada papel pode ser representado por mais de uma pessoa, ou uma pessoa pode ter mais de um papel, dependendo da carga de trabalho necessário. Porém o RUP aborda os papéis em maior detalhe. Ao todo são mais de 30. Exemplos de papéis e analise de sistemas.
Modelos de documentos: O RUP apresenta modelos e exemplos para os diversos documentos artefatos (artifacts) gerados ao longo do projeto. Estes documentos são descritos em detalhe.

8. Conclusões
Com base nestes recursos a adoção do RUP pode ser feita de mais de uma maneira. Um extremo seria usar o RUP à risca, ou seja, aplicar todos os métodos e processos exatamente como são propostos. A vantagem desta abordagem é que nada deve ser alterado, pois o RUP é bem completo e detalhado. Porém existe um preço a ser pago, pois o RUP na íntegra é complexo. Esta abordagem implicaria em treinamentos, projetos piloto, etc.
O extremo oposto seria adotar outro modelo de processo mais simples ou conhecido (o atual, se existir) utilizar o material do RUP como fonte de referência complementar para assuntos não abordados em outro modelo como, por exemplo, os modelos de documentos.
A primeira abordagem é interessante para empresas que precisam de uma grande formalização do processo de desenvolvimento de software e cujo método atual seja totalmente inadequado ou inexistente. A segunda abordagem seria interessante para quem já tem alguma metodologia que considera adequada, mas que tem deficiência em alguma área como, por exemplo, suporte a UML. Soluções intermediárias também são possíveis.

Referências:

[1] DATASUS, GPSL- Gerência de Padrões e Software Livre. Home Page. Disponível em: . Acesso em: Outubro 2006.

[2] IBM, Software Corporation, Introdução ao Processo Unificado da IBM-Rational. Home Page. Disponível em: . Acesso em: Outubro 2006.

[3] TONSIG, Sergio Luiz – Engenharia de Software. Futura, São Paulo, 2003.

PS. Escrito em novembro de 2006.
Postado por Carlos A Pereira às 22:10 0 comentários



================================================================================================



Artigo - Metodologia de Desenvolvimento Ágil – XP (Extreme Programming)
Metodologia de Desenvolvimento Ágil – XP (Extreme Programming)
Faculdades Associados de Santa Catarina (FASC)
Rua . Henrique Lage, – Centro – 88.806-000 – Criciúma – SC – Brasil
Carlos Aurélio Pereira
billsombrio@gmail.com

Resumo. A metodologia Ágil XP, abreviação de Extreme Programming (ou Programação extrema), é uma metodologia que ainda conta com alguns outros métodos de desenvolvimento ágil sempre voltado a fazer com que o Cliente faça parte do desenvolvimento do projeto, códigos claros e simples, equipe de desenvolvedores integradas, enfim, tudo para agilizar o desenvolvimento do projeto. O radicalismo de alguns pensadores de XP afastam a compreensão sobre as reais vantagens e os benefícios para o negócio que podemos alcançar com estes métodos.




Introdução
Metodologia de Desenvolvimento Ágil voltada para equipes pequenas a média, que não tem uma análise completa do projeto disponível e portanto sofrendo constantes mudanças. Esta metodologia é composta por uma série de métodos um tanto radicais para agilizar o desenvolvimento de Projetos.



* Pair Programming;

* Continuous Integration;

* Stand-Up Meeting;

* Collective Ownership (código fonte coletivo);

* Refactoring;

Pair Programming (Programação em Duplas)
Este método da metodologia XP visa que os códigos sejam desenvolvidos em dupla, para que o codigo ao mesmo tempo que seja desenvolvido já seja revisado. Autores sobre tal método defendem que há um ganho de cerca de 50% na questão de códigos defeituosos, ou seja, códigos que não precisarão voltar para o setor de Desenvolvimento após algum teste.

Continuous Integration (Integração Contínua)

A proposta deste método é fazer com que todas as implementações novas do projeto já sejam disponibilizadas imediatamente, não aguardando prazos como liberações de releases ou algo do tipo. Sendo assim já se fica sabendo se tais interações não irão criar conflitos muito tarde.

Stand-up Meeting (Reuniões feitas em pé)
As conversas informais ou mesmo formais mais produtivas que podemos nos lembrar, sem sombra de dúvidas foram em pé. Onde você está inteiramente concentrado no que está fazendo e falando. Está é a maneira que a metodologia XP prevê para a realizações de reuniões. Levando o tempo necessário para debater o assunto e somente aquele assunto. Diferentemente do método convencional onde muito sabemos que a distração e a perca de foco ocorre com muita facilidade, talvez até pelo conforto de estar sentado.

5. Collective Ownership (Posse Coletiva do Código Fonte)
Esta abordagem sobre a posse de determinados códigos fonte dentro de um projeto prevê que todos os colaboradores alterem a qualquer tempo qualquer trecho de código. Não tendo que ficar pedindo permissões para tal, ou destinando certos módulos a apenas alguns programadores. Desta forma a equipe inteira é forçada a conhecer todo o projeto.
6. Refactoring
Este método considera que devemos sempre estar reescrevendo nossos códigos para sempre estar melhorando e aprimorando-os, evitando re-escrita de códigos em muitos trechos do programa uma vez que uma série de rotinas vem sendo re-avaliadas a partir do crescimento e necessidade do projeto.

7. Conclusões
Com base nesta tecnologia que visa a agilidade e a desburocratização do desenvolvimento, temos augumas partes nem tam agil se formos isolalas mais em um todo se torna uma metodologia agil e descentralizada.

Referências:

[1] Revista Visão Ágil – Edição 02, Home Page. Disponível em: . Acesso em: Setembro 2008.

[2] TONSIG, Sergio Luiz – Engenharia de Software. Futura, São Paulo, 2003.

PS. Escrito em 28 de novembro de 2008.
Postado por Carlos A Pereira às 22:01 0 comentários

Pagamento Global

Imagens de solução